Clarify sidecar restart and shutdown semantics #126

New Issue

2026-06-02T03:42:37-04:00

didericis-codex commented

2026-06-02 03:42:37 -04:00

Problem

Issue #117 identifies bot_bottle/sidecar_init.py as a complexity hotspot. The concrete concern from didericis-claude's review is that the SIGUSR1 handler calls sup.restart_daemon("pipelock") directly from signal context. That path can run subprocess.Popen, create threads, terminate processes, and wait with a timeout while the signal handler is executing. In CPython signals run between bytecodes in the main thread, but the current shape still lets restart work block the supervisor loop and makes stacked signals harder to reason about.

The same review also notes that exit_code() documents graceful shutdown as returning 0, but a child that crashed before shutdown can still make the aggregate code nonzero.

Desired outcome

Add a PRD for tightening sidecar restart and shutdown semantics without changing the sidecar contract unnecessarily. The PRD should cover:

moving signal-triggered restart work out of direct signal-handler execution
preserving existing SIGUSR1 behavior from callers' perspective
clarifying aggregate exit-code semantics after crashes and graceful shutdown
focused tests for restart requests, stacked signals, shutdown ordering, and exit-code reporting

Parent context

Carved out from the broader hotspot review in #117.

## Problem Issue #117 identifies `bot_bottle/sidecar_init.py` as a complexity hotspot. The concrete concern from didericis-claude's review is that the SIGUSR1 handler calls `sup.restart_daemon("pipelock")` directly from signal context. That path can run `subprocess.Popen`, create threads, terminate processes, and wait with a timeout while the signal handler is executing. In CPython signals run between bytecodes in the main thread, but the current shape still lets restart work block the supervisor loop and makes stacked signals harder to reason about. The same review also notes that `exit_code()` documents graceful shutdown as returning 0, but a child that crashed before shutdown can still make the aggregate code nonzero. ## Desired outcome Add a PRD for tightening sidecar restart and shutdown semantics without changing the sidecar contract unnecessarily. The PRD should cover: - moving signal-triggered restart work out of direct signal-handler execution - preserving existing SIGUSR1 behavior from callers' perspective - clarifying aggregate exit-code semantics after crashes and graceful shutdown - focused tests for restart requests, stacked signals, shutdown ordering, and exit-code reporting ## Parent context Carved out from the broader hotspot review in #117.

didericis-codex referenced a pull request that will close this issue

2026-06-02 03:43:55 -04:00

PRD 0034: Sidecar Restart and Shutdown Semantics #127

didericis added the Kind/Enhancement label 2026-06-02 03:50:20 -04:00

didericis closed this issue

2026-06-02 03:55:06 -04:00

didericis-codex referenced this issue

2026-06-02 03:55:59 -04:00

Complexity hotspots in launch, egress, and auth paths #117

Sign in to join this conversation.