Files
Charlie CheeverandClaude Opus 5.5 410bd21887 A timed-out storage write keeps its place in the queue until it completes
When an answer's native storage wait runs out, the answer fails and its
unsent operations are rejected, as is any storage its continuations issue
afterwards. The operation in flight may still commit (an atomic write
stalled in sync or rename), so it stays at the head of the module's
queue, owned by the background, until its real completion: a later
write can no longer overtake it. Image work whose right to write was
revoked still releases its place at once; its cancellation is bound to
the current head's native Promise.

A lock's unlock() from a failed answer's finally still runs, as module
work queued behind that write. A lock stays tracked until the queue
accepts its release, so a refused release is freed with its answer.

In a let-go chain, a non-image timeout fails only the answer whose write
is in flight. Other let-go answers keep their queued storage, which a
background round delivers once that write completes.

Retiring a worker signals its storage wait apart from its job queue: the
retired worker releases its waiter and VM, drops unstarted work, and lets
already-submitted native operations finish.

The native Promise getter is captured and removed during bootstrap, and
its web counterpart exposes only image Promises, so application code
cannot reach a raw database capability around the queue.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-11-13 15:29:02 -08:00
..