Give back a claim that the EXECUTION FENCE refused, then re-throw.
Homed here, beside the state machine, rather than written out at each start
site: the rollback is only correct for this one error family, and a copy that
widened its catch — to "any start failure", say — would hand the next retry a
fresh run after a start that may well have executed. Keeping the predicate
and the CAS in one function is what stops that widening from being a one-line
edit somebody makes in a hurry.
THE CLASS INVARIANT THIS RELIES ON. Giving a claim back is only sound for a
failure that provably executed NOTHING, and that is a property of the two
fence refusal codes rather than of the JavaScript class carrying them:
EXECUTION_FENCED is authored at a gate — the run object's start
route, before any of its own reads or writes,
and RunnerRuntime.#assertStartFence, before
the run lock and before core mints anything.
EXECUTION_FENCE_UNREADABLE is authored by the fence READ that fronts those
same gates, which is even earlier.
Neither code is reachable from anywhere past the point of execution, so a
refusal carrying one is pre-execution wherever it was observed.
Which is why the predicate is isExecutionFenceRefusal — the widened one,
which admits the wire rebuild — and NOT instanceof ExecutionFencedError.
Both of this function's callers sit on the far side of a Durable Object
boundary in every DO-backed host: the run object throws, doErrorResponse
renders, and doSummary (or the agent topology's errorFrom) rebuilds a
RunRouteError carrying the same status and the same structured reason but
not the same class. An instanceof-only test would answer "not a fence
refusal" for exactly the deployments this rollback exists to protect, and a
drained-then-reopened deployment would find every key that was in flight
permanently stuck at UNRESOLVABLE. In-process hosts (a { storage } runtime
wired straight into the router) do throw the class, so both shapes are live
and one predicate has to cover them.
The rollback itself is best-effort: it runs while the deployment is already
refusing to execute, so its own failure must not replace the fence's refusal
with a storage error the caller cannot act on. A rollback that does not land
leaves an UNRESOLVABLE reservation — recoverable by investigation — while a
swallowed fence refusal would leave the caller believing the deployment is
broken rather than fenced.
Give back a claim that the EXECUTION FENCE refused, then re-throw.
Homed here, beside the state machine, rather than written out at each start site: the rollback is only correct for this one error family, and a copy that widened its catch — to "any start failure", say — would hand the next retry a fresh run after a start that may well have executed. Keeping the predicate and the CAS in one function is what stops that widening from being a one-line edit somebody makes in a hurry.
THE CLASS INVARIANT THIS RELIES ON. Giving a claim back is only sound for a failure that provably executed NOTHING, and that is a property of the two fence refusal codes rather than of the JavaScript class carrying them:
EXECUTION_FENCED is authored at a gate — the run object's start route, before any of its own reads or writes, and
RunnerRuntime.#assertStartFence, before the run lock and before core mints anything. EXECUTION_FENCE_UNREADABLE is authored by the fence READ that fronts those same gates, which is even earlier.Neither code is reachable from anywhere past the point of execution, so a refusal carrying one is pre-execution wherever it was observed.
Which is why the predicate is
isExecutionFenceRefusal— the widened one, which admits the wire rebuild — and NOTinstanceof ExecutionFencedError. Both of this function's callers sit on the far side of a Durable Object boundary in every DO-backed host: the run object throws,doErrorResponserenders, anddoSummary(or the agent topology'serrorFrom) rebuilds aRunRouteErrorcarrying the same status and the same structured reason but not the same class. An instanceof-only test would answer "not a fence refusal" for exactly the deployments this rollback exists to protect, and a drained-then-reopened deployment would find every key that was in flight permanently stuck at UNRESOLVABLE. In-process hosts (a{ storage }runtime wired straight into the router) do throw the class, so both shapes are live and one predicate has to cover them.The rollback itself is best-effort: it runs while the deployment is already refusing to execute, so its own failure must not replace the fence's refusal with a storage error the caller cannot act on. A rollback that does not land leaves an UNRESOLVABLE reservation — recoverable by investigation — while a swallowed fence refusal would leave the caller believing the deployment is broken rather than fenced.