Problem
During an active-session shutdown on Detent v0.48.0 (87d1438), the drain banner appears correctly, but the HTTP listener stops answering /health. A second SIGTERM then reaches the force path, yet the process exits with a misleading github_auth error caused by canceled-context token resolution instead of the primary forced-shutdown result.
The initial wait itself was expected because two sessions were active. The regressions are loss of draining observability and shutdown-result misclassification.
Live evidence
Observed on 2026-07-22:
- First SIGTERM printed:
shutdown requested; draining sessions; press Ctrl+C again to force quit immediately
- Two Codex sessions were still active, so drain mode was legitimate.
- The Detent process continued listening on
127.0.0.1:4000, but GET /health timed out after 3 seconds with no response.
- A second SIGTERM printed:
force quit requested; interrupting sessions
- Instead of a forced-shutdown result, the final structured error was:
code: github_authdetail: resolve github_token via gh auth token: context deadline exceededexit_code: 2
Related closed issues #383 and #1227 explicitly require /health and /api/v1/state to report draining and require deterministic second-signal semantics.
Expected behavior
Drain mode remains observable, and cancellation noise from connector/auth work cannot replace the shutdown state machine’s primary outcome.
Acceptance criteria
- While draining,
/health responds promptly with a draining status and active-session count.
/api/v1/state remains readable enough to show drain progress until teardown begins.- A second SIGINT/SIGTERM deterministically produces the forced-shutdown sentinel/result.
- Context-canceled connector, token, metrics, and store work during teardown is logged as secondary cleanup noise and cannot be classified as a new auth failure.
- Tests cover first signal during a slow connector refresh, health requests during drain, and second-signal error precedence.
- The forced path terminates owned worker process groups and exits within the documented hard deadline.
Problem
During an active-session shutdown on Detent v0.48.0 (
87d1438), the drain banner appears correctly, but the HTTP listener stops answering/health. A second SIGTERM then reaches the force path, yet the process exits with a misleadinggithub_autherror caused by canceled-context token resolution instead of the primary forced-shutdown result.The initial wait itself was expected because two sessions were active. The regressions are loss of draining observability and shutdown-result misclassification.
Live evidence
Observed on 2026-07-22:
shutdown requested; draining sessions; press Ctrl+C again to force quit immediately127.0.0.1:4000, butGET /healthtimed out after 3 seconds with no response.force quit requested; interrupting sessionscode: github_authdetail: resolve github_token via gh auth token: context deadline exceededexit_code: 2Related closed issues #383 and #1227 explicitly require
/healthand/api/v1/stateto report draining and require deterministic second-signal semantics.Expected behavior
Drain mode remains observable, and cancellation noise from connector/auth work cannot replace the shutdown state machine’s primary outcome.
Acceptance criteria
/healthresponds promptly with a draining status and active-session count./api/v1/stateremains readable enough to show drain progress until teardown begins.