Repository navigation
Know when a process ended due to the child_process.spawn() timeout option #51561
Description
Activity
Another alternative is to pass an AbortSIgnal:
import {spawn} from 'node:child_process' const signal = AbortSignal.timeout(2e3) const childProcess = spawn('node', ['-e', 'setTimeout(() => {}, 1e7)'], { signal, stdio: 'inherit', // no stdout/stderr }) childProcess.on('error', (err) => { console.log({err, didTimeout: signal.aborted}) // { err: [AbortError], didTimeout: true } }); childProcess.on('exit', (exitCode, killSignal) => { console.log({exitCode, killSignal, didTimeout: signal.aborted}) // { exitCode: null, killSignal: 'SIGTERM', didTimeout: true } })
Setting childProcess.timedOut = true is an easy and convenient implementation. We could go with AbortSignal, but just checking a flag keeps things really simple. Opened a PR implementing it!
import { spawn } from 'node:child_process'; const childProcess = spawn('node', ['-e', 'setTimeout(() => {}, 1e7)'], { timeout: 2e3, stdio: 'inherit', // no stdout/stderr }); childProcess.on('exit', (exitCode, signal) => { console.log(childProcess.timedOut); // true console.log({ exitCode, signal }); // { exitCode: null, signal: 'SIGTERM' } });
Reacted by ehmickyThere has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-stale
Issues and PRs exempt from automated stale handling. label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-stale
Issues and PRs exempt from automated stale handling. label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.Please keep this open.
Reacted by Kevin A. Mitchell, Anders Skouboe, Sam Huang and ehmickyThere has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-stale
Issues and PRs exempt from automated stale handling. label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.4 remaining items
Please keep this open.
Is there a way to spped this merge? Its been a while since this was opened
- added a commit that references this issue
on Feb 9, 2026 Sooonnnnn it will be merged
This issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.Please keep this open.
Please keep this feature I'm testing on it.
I think I should also check for manual kill
oh! I got it.
What is the problem this feature will solve?
When a process ends due to the
timeoutoption ofchild_process.spawn(), there is no way to know whether that termination was due to the timeout. ASIGTERMis sent to the process, but that's pretty much it.This makes debugging harder. Some users might be left wondering why the process ended if they don't pay attention to the
timeoutoption.What is the feature you are proposing to solve the problem?
Having a way to know whether the process ended due to the
timeoutoption. Any implementation would work. Some potential ideas:timeoutevent onchildProcesstimedOutpassed to theexiteventerrorevent witherror.code: 'ETIMEDOUT'onchildProcess. This is a breaking change since many users are currently listening forerrorevents, so would probably not be a good idea.childProcess.timedOut = truechildProcess.timedOut()returning a booleanWhat alternatives have you considered?
One could possibly set a manual timeout like the following.
However, it defeats some of the convenience of the
timeoutoption, since that one might as well callchildProcess.kill()themselves then. Also, it is slightly unreliable since an unrelatedSIGTERMcould theoretically have been sent at the exact same time.