Stop is a durable-state problem: the cancelled agent run your restart brings back

A post on dev.to makes a narrow and useful argument: a stop button is not a cancellation protocol, because by the time an operator clicks it the work may already be queued, claimed by another worker, sitting inside a browser session, or waiting on an outbound side effect [s1c1]. The consequence is the part worth caring about: if cancellation is not represented as durable state, a restart can resurrect work the operator thought they stopped [s1c2]. The reframing is to stop asking whether the process received SIGTERM and instead ask whether every layer can prove three things: whether this run may still start work, whether in-flight work must finish, and what happened to side effects that were interrupted [s1c20]. That means cancellation has to be kept separate from process liveness. A worker can be alive while its run is cancelled, and a worker can die before it records the cancellation [s1c3]. The proposed minimum is five run states: ACTIVE, where new work may be admitted; CANCELLING, where no new work starts and in-flight work is observed or stopped; CANCELLED, where the run will not resume and no unclaimed step may dispatch; COMPLETED; and UNKNOWN, where the controller cannot prove whether an external effect happened [s1c4]. The row is stored durably with a monotonically increasing cancel_version, illustrated in the piece as run_42 / CANCELLING / 3 [s1c5]. Workers carry the version they observed, and a dispatch is only valid if the durable row still says ACTIVE at that same version, which closes the race where Stop is pressed after a worker checked the run but before it starts a tool call [s1c6]. This is why the article insists the critical operation is a compare-and-set rather than a read followed by a write: the transition to CANCELLING increments cancel_version and only applies where status is still ACTIVE [s1c15]. Worker dispatch is guarded the same way, with the step update conditioned on an existence check against the run row at the exact observed version [s1c16]. If that update affects zero rows, the worker must not call the tool; it releases the claim and records CANCELLED_BEFORE_DISPATCH [s1c17]. A check at the top of the agent loop is too weak. The contract has to be enforced at every boundary that can create work, and the piece names six: admission, queue claim, tool dispatch, retry scheduling, browser actions, and outbound delivery [s1c7][s1d1]. Two of those carry the most operational weight. Cancellation must revoke future retries, not just the current attempt [s1c8]. And delivery policy is independent of execution cancellation: cancelling a code-generation run does not prove that an already-created notification was unsent, so execution and delivery need separate records [s1c9]. The honest-failure discipline follows. Do not mark a run CANCELLED merely because the worker process exited, since a process can die after sending a request and before recording the response [s1c12]. For every external side effect, record an intent with a stable key before dispatch, then reconcile UNKNOWN with the provider's lookup API, a webhook, or an operator decision [s1c13]. A cancellation timeout should land in UNKNOWN or CANCELLING_TIMEOUT rather than silently in success or cancellation, so the ambiguity is visible instead of becoming duplicate work on restart [s1c14]. Cooperative cancellation, where the worker notices the state change at a safe checkpoint and exits, is the default; forced cancellation is the deadline for the worker that will not cooperate [s1c10]. The sequence runs ACTIVE to CANCELLING with admission and retries revoked, then a drain of safe checkpoints, then CANCELLED if nothing is in flight or UNKNOWN if an external effect cannot be reconciled [s1c11]. What to watch in your own implementation is the evidence requirement, not the state names: for each injected failure the article asks you to assert no unauthorized new effect, no lost cancellation intent, and a record an operator can explain later [s1c18].