Reliability field note · 2026-07-20
Cleanup bugs live at the process boundary
Why cancellation, bind, and retry windows deserve executable proofs rather than source-level suspicion.
Starting a process is not one atomic action. There is a window between creation, registration, binding, and ownership becoming visible to the rest of the runtime. Cancellation and retry do not politely wait for that window to close.
Two versions of the same boundary
In Open Design, a failed attempt could enter same-run retry while its old process group remained alive. PR #5463 made cleanup part of the attempt transition instead of a best-effort detail after it.
In Omnigent, cancellation during the runner’s spawn-and-bind window could leave the child alive before an owning entry was fully installed. PR #1982closed that narrower race.
Why reading the code was not enough
Cleanup code is full of branches that look defensive. The question is whether the failing timing actually reaches them. A controlled fake child process can pause at the bind boundary, accept a cancellation at a precise moment, and expose whether the PID remains alive afterward.
If the reproduction cannot control the timing, the test may only prove that the race did not happen today.
The reusable rule
Model child-process ownership as a state machine. Every state entered after spawn must have one deterministic path that reaps the child, including cancellation and retry transitions that occur before normal registration finishes.