Optionalopts: { onError?: (err: unknown, label?: string) => void }Enqueues task to run after all prior tasks for key have settled. Fire-and-forget: returns
the task's result promise, but the caller need not await it — it resolves to the task's value on
success or undefined on failure, and never rejects. Failures (a thrown error, or a resolved
value opts.isOk deems falsy) are counted for flush and routed to onError.
Serialization key (object identity). Same key → serialized; different keys → concurrent.
The work to run.
Optionalopts: {Optionalafter?: objectOptional dependency key — the task waits for this key's latest task to settle before running, in addition to waiting for its own key's prior tasks. Use this to honour cross-instance ordering constraints like self-referencing foreign keys (e.g. a child step's INSERT must land after its parent step's INSERT). This is the in-queue form of the wait; when the dependent write lives in a different queue, use Settled instead.
OptionalisOk?: (v: T) => booleanTreats a resolved value as a failure when it returns false (e.g. Save() → false).
Optionallabel?: stringDiagnostic label passed to onError.
Optionalready?: Promise<void>Optional promise the task also waits for. Use it when the task depends on work
outside this queue — typically another queue's Settled, so a child row waits for a parent
row that a different queue is writing. The task is queued (and counted by Flush) at once;
only its start is held back, so the caller never waits. A rejected ready still runs the task,
the same as a failed prior task: the task's own outcome is what gets tallied.
Use Flush.
Awaits the currently in-flight tasks, then reports and resets the failure tally accumulated since the last flush. Tasks enqueued after this call begins are not awaited here.
Resolves once every task enqueued so far for key has settled — at once when the key has no
pending task. The cross-queue form of Enqueue's after option: after can only see keys in this
instance, so a caller that must order a write in another queue behind this key awaits this instead.
A pure read: it never rejects (a failed task is already tallied and routed to onError), and it
neither enqueues anything nor delays later tasks. Tasks enqueued after the call are not awaited.
A per-key serial task chain. Tasks for the same key (compared by object identity) run one at a time in enqueue order; tasks for different keys run concurrently. Enqueuing is fire-and-forget — the returned promise never rejects, and failures are tallied for flush.
This is what makes "mutate after the prior task lands" structural: a task enqueued after another on the same key physically cannot begin until the prior one resolves.