Expand description
Input completion waiters — allows callers to await the execution outcome of an accepted input.
When a surface accepts an input via the runtime, it can optionally receive a
CompletionHandle. It normally resolves when the input reaches a terminal
state (Consumed or Abandoned). If an execution attempt fails durably and the
machine requeues the input, the process-local handle resolves that generated
attempt failure without terminalizing the durable input. This bridges the
async accept/await pattern needed for surfaces that want synchronous-feeling
turn execution through the runtime.
CompletionRegistry is waiter plumbing only. Production code must never
treat waiter presence, waiter counts, or sender membership as semantic
runtime truth.
Structs§
- Completion
Cleanup Observation - Runtime-minted observation for post-completion cleanup.
- Completion
Handle - Handle for awaiting the completion of an accepted input.
- Completion
Registry Snapshot - Diagnostic snapshot of the completion waiter registry.
- Completion
Waiter Entry Snapshot - Snapshot of one input’s registered completion waiters.
Enums§
- Completion
Outcome - Outcome delivered to a completion waiter.
- Completion
Wait Error - Mechanical failure while waiting for completion plumbing.
Functions§
- interaction_
terminal_ event - Project one generated-authority completion onto the canonical interaction-scoped terminal event. Both the comms live stream and durable placed-turn observation use this single mapping so result/failure semantics cannot drift between surfaces.