CLIEntry's start hook no longer registers its own handler for SIGINT and SIGTERM. fx already stops the daemon on both signals and sets the exit code, as GO_HTTP_SERVER_CONVENTIONS.md "Signal Handling and Graceful Shutdown" requires. The extra handler made every stop signal ask fx for a second shutdown and log "Received shutdown signal" next to fx's own stop. It also stayed registered after the stop. The stop deadline from #100 is unchanged.
The "Failed to shutdown gracefully" message is still logged in one place: when Run fails and asking fx to stop with status 1 fails too.
Disclosures:
Deviation from the issue: with fx v1.24.0 a clean stop does not log "Failed to shutdown gracefully". fx's Run is already waiting when the signal arrives, so the first request goes straight to it and the second fits in the free slot of its channel. The extra call fails only if the signal arrives in the instant before Run starts waiting. On the image built from next before this change, a stop always logged the second handler's line and never the failure.
No test: before the change, a stop signal already met the definition of done (one stop, no failure line, exit 0), so no test of those three could fail first. A test would also need CLIEntry, which connects to RIS Live. The definition of done's other option was used instead: docker stop on the built image, with its exit status and log checked.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/routewatch/issues/131.
`CLIEntry`'s start hook no longer registers its own handler for SIGINT and SIGTERM. fx already stops the daemon on both signals and sets the exit code, as `GO_HTTP_SERVER_CONVENTIONS.md` "Signal Handling and Graceful Shutdown" requires. The extra handler made every stop signal ask fx for a second shutdown and log "Received shutdown signal" next to fx's own stop. It also stayed registered after the stop. The stop deadline from https://git.eeqj.de/sneak/routewatch/issues/100 is unchanged.
The "Failed to shutdown gracefully" message is still logged in one place: when `Run` fails and asking fx to stop with status 1 fails too.
Disclosures:
- Deviation from the issue: with fx v1.24.0 a clean stop does not log "Failed to shutdown gracefully". fx's `Run` is already waiting when the signal arrives, so the first request goes straight to it and the second fits in the free slot of its channel. The extra call fails only if the signal arrives in the instant before `Run` starts waiting. On the image built from `next` before this change, a stop always logged the second handler's line and never the failure.
- No test: before the change, a stop signal already met the definition of done (one stop, no failure line, exit 0), so no test of those three could fail first. A test would also need `CLIEntry`, which connects to RIS Live. The definition of done's other option was used instead: `docker stop` on the built image, with its exit status and log checked.
Model: opus-5-5
The start hook registered its own handler for SIGINT and SIGTERM and
asked fx to shut down from it, although fx already stops the daemon on
both signals. A stop signal was handled twice, and the handler stayed
registered after the stop. fx now handles both signals alone, as
GO_HTTP_SERVER_CONVENTIONS.md "Signal Handling and Graceful Shutdown"
requires.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #131.
CLIEntry's start hook no longer registers its own handler for SIGINT and SIGTERM. fx already stops the daemon on both signals and sets the exit code, asGO_HTTP_SERVER_CONVENTIONS.md"Signal Handling and Graceful Shutdown" requires. The extra handler made every stop signal ask fx for a second shutdown and log "Received shutdown signal" next to fx's own stop. It also stayed registered after the stop. The stop deadline from #100 is unchanged.The "Failed to shutdown gracefully" message is still logged in one place: when
Runfails and asking fx to stop with status 1 fails too.Disclosures:
Runis already waiting when the signal arrives, so the first request goes straight to it and the second fits in the free slot of its channel. The extra call fails only if the signal arrives in the instant beforeRunstarts waiting. On the image built fromnextbefore this change, a stop always logged the second handler's line and never the failure.CLIEntry, which connects to RIS Live. The definition of done's other option was used instead:docker stopon the built image, with its exit status and log checked.Model: opus-5-5
Review passed.
Model: opus-5-5