SessionApplyOutcome

What one Session.apply did: the fold’s own outcome, plus any pending-command retirements the event triggered.

Retirements ride the return value rather than a stream, matching the pull model the pending set already uses: every retirement is returned synchronously by the mutator that produced it — with ONE stated exception.

THE EXCEPTION. A frame HELD during an fill reports bufferedDuringGap with retirements: [], because at that moment nothing has folded. Its real effects — an reclaim, an approval round trip — happen when the fill splices, and they surface on the io of the EARLIER view/gap apply that started the fill, never on the buffered frame’s own return. A consumer reconciling retirements frame by frame must therefore keep the gap frame’s outcome and await its io, or it will read [] for a reclaim that really happened.

A SECOND view/gap that lands while a fill is running rides the same channel for the same reason: it extends the running walk instead of starting its own, so its apply reports deliveryGap with an already-settled empty io, and the work it caused settles on the FIRST gap frame’s.

Properties

Property	Type	Stability	Presence	Description
fold	FoldOutcome | SessionApplyRefusal | SessionGapBuffered | SessionGapOverlap		required
io	Promise<readonly PendingRetirement<I>[]>		required	The client->server I/O this event triggered, settled — the replays queue movement demands, and ’s approval/decide submission. Resolves to the retirements that I/O produced.
retirements	readonly PendingRetirement<I>[]		required

Source

clients/sdk-ts/src/facade/session.ts:244

{
  "kind": "Interface",
  "canonicalPath": "SessionApplyOutcome"
}