Add exit(code): stop the system, then exit the process with the code - #21
Merged
Merged
Conversation
An application which gives up, from a component_failed listener or a
fatal error handler, had to write the stop-then-process.exit dance itself,
although exitOn already performed it in lib/exit.js. That primitive is
now public as system.exit(code), and exitOn is: on each signal, call
exit() with no code.
After a successful stop the process exits with the given code. After a
failed stop the caller's non-zero code is kept and 0 or none becomes 1:
the caller's reason for exiting outranks the stop's failure, which the
events announce anyway. The alternative, always 1 as exitOn did, would
lose a fatal handler's code on the way to the orchestrator.
Three things found empirically shape the code. On Node 24
process.exit(undefined) is an explicit 0 and does not honour
process.exitCode, so the no-code path calls a bare process.exit(); the
existing restart scenario, which expects exitCode 3, caught the
difference. Signal listeners are called with the signal's name and
number, and process.exit('SIGTERM') throws, so exitOn's listener
discards its arguments; a new scenario raising a real SIGTERM is the
only one which catches that, since custom events carry no arguments.
A signal listener does not keep the event loop alive, so the child
program's postgres now holds a timer the way a server holds a socket.
Closes #20.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Welcome to Codecov 🎉Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests. Thanks for integrating Codecov - We've got you covered ☂️ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #20.
system.exit(code)stops the system and exits the process once the stop has finished.exitOnbecomes: on each signal, callexit()with no code. Its observable behaviour is unchanged.Behaviour
process.exit(), soprocess.exitCodeis honoured.exitOndid, would lose a fatal handler's code on the way to the orchestrator.Found empirically
process.exit(undefined)is an explicit 0 and does not honourprocess.exitCode. The existing restart scenario, which expects code 3, caught it.process.exit('SIGTERM')throws. The custom-event scenarios carry no arguments, so a scenario raising a real SIGTERM was added; it is the only one which catchesexitOnpassing its arguments through.Tests
Six new child-process scenarios and three in-process validation scenarios in test/features/exiting.md. Each deliberate breakage is caught, detailed in #20. 1339 steps pass, lint and typecheck clean.
🤖 Generated with Claude Code