You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
guardedWrite: make the per-path FIFO chain cancellation-aware so an aborted queued write is released promptly #2153
guardedWrite (#1405, S4a) serializes in-process writes to the same absolute path through a per-path FIFO chain (pendingChains tail promise). Each queued link runs when its predecessor settles, and the link checks task.abort when its turn arrives.
The residual problem (pre-merge warning on #1405): a task that is aborted or disposed while its write is still queued behind a predecessor keeps the queued link (and the closure over its task/content) alive until the predecessor settles. If the predecessor is slow or hung, the queued caller waits for the abort latency and the chain retains the task longer than necessary.
Why it is a follow-up, not an in-PR patch
Task exposes abort: boolean but no abort event or disposed promise, so a queued link cannot be woken at abort time without adding a signal source to the task lifecycle (Task.abortTask/dispose). That lifecycle surface is shared with the run-state units (#1921 and the turn sub-machine), so the signal should be added once, deliberately, rather than as polling inside this core.
Proposed design
Add a disposal/abort signal to Task (an AbortSignal resolved in abortTask() and in dispose(), since dispose sets the same abort flag).
In guardedWrite, enqueue a link whose promise races the signal: on abort the caller rejects immediately with the existing cancellation message.
Let the aborted link settle its chain slot as soon as it reaches its turn (settle-and-skip), and delete the pendingChains entry when it is the tail, so no task closure is retained after abort.
Preserve FIFO ordering for writes that are still live: an aborted link must not let a later write run concurrently with the still-running predecessor.
Acceptance criteria
A write queued behind a never-settling predecessor rejects promptly (~immediate) when its task aborts or is disposed.
The aborted link releases its pendingChains entry once it is the tail, and the entry no longer retains the task or content.
Live writes keep strict FIFO ordering (no overlap after an abort).
Tests cover abort-before-enqueue, abort-while-queued, and abort-while-running.
Activity