SessionApplyOutcome

What one Session.apply did.

Class in muse_code

Properties

Property	Type	Description
fold	Union[FoldOutcome, SessionApplyRefusal, SessionGapBuffered, SessionGapOverlap]	The fold’s own outcome, or this layer’s own verdict (the discard refusal, the mid-fill buffering, the overlap refusal).
retirements	tuple[PendingRetirement[_I], ...]	The pending-command retirements the event triggered synchronously. ONE stated exception: a frame HELD during an fill reports bufferedDuringGap with no retirements, because at that moment nothing has folded — its real effects surface on the io of the EARLIER view/gap apply that started the fill, never on the buffered frame’s own return. A second view/gap landing mid-fill rides the same channel: it extends the running walk, so its own io is empty.
io	Awaitable[tuple[PendingRetirement[_I], ...]]	The client->server I/O this event triggered, settled — resolves to the retirements that I/O produced. A SEPARATE channel from retirements because apply is synchronous by contract: a consumer’s notification pump must not await a round trip before it can fold the next frame. IT NEVER REJECTS — a replay whose transport failed proves nothing about the intake, so its entry holds and the authoritative report is the host-death notification already on its way; an approval failure reports to on_approval_error and a fill failure to on_gap_error.

Source

clients/sdk-py/src/muse_code/facade/session.py:324