The \"msecs\" argument must be of type - Frequent ...
# support
d
There's an error happening frequently on my deployed server and causing it to restart, which interrupts users the whole error text
Copy code
[medplum] [2025-03-26 22:17:41] {"level": "ERROR", "timestamp": "2025-03-26T22: 17:41.151Z", "msg": "Uncaught exception thrown", "error":
LID_ARG_TYPE]: The \"msecs\" argument must be of type number. Received type string ('600001000')", "stack": ["TypeError CERR_INVALID ecs\" argument must be of type number. Received type string ('600001000')"
at getTimerDuration (node: internal/timers:426:3)"
reamTimeout [as setTimeout] (node:internal/stream_base_commons: 243:11)",
node: events: 519:35)","
at resOnFinish (node:_http_server: 1017:14)","
at S
at onFinish (node:_http_outgoing: 1081:10)","
at afterWrite (node: internal/streams/writable:708:5)","
(node: internal/streams/writable: 694:10)","
at process.processTicksAndRejections (node:internal/process/task_queues: 89:21) "]}
[medplum]
[] exited with exit code
Unsure what could be causing it, I don't see where those libraries are called, or arguments with that name
c
Hm, interesting. I don't recall seeing that error message before, and unfortunately the stack trace isn't very helpful. We only use
setTimeout
directly in a handful of cases, mostly around the Medplum Agent. Are you using the Agent? The next most likely candidate would probably be somewhere inside BullMQ for job management. Are you using Medplum cron jobs? Google turns up basically zero results for "CERR_INVALID", so that is a puzzler. We can look to see if there's a way to log more details inside the "uncaught exception" handler.
Hm - one other possibility, are you using the
shutdownTimeoutMilliseconds
server config setting?
d
Yes, i could't find any references to where is happening I don't have data on this instance, so I think I'm gonna destroy it and try again, It was left unatended for a while
183 Views