pub fn resolve_wait(
observation: &WaitObservation,
request: &WaitRequest,
) -> Option<WaitDecision>Expand description
Decide whether this observation ends the wait.
A wait answers for one turn, so only the turn’s own fate ends it. In
particular a session that is carrying an error from some earlier, unrelated
action is not a reason to fail the turn the caller asked about: the session
error badge has no expiry, and reporting it here made every later wait on
that session return error while the turn ran on perfectly well.
The rules run in order, and the order is the point:
- A resume running for this session ends nothing: it is a session coming up, and its durable record says stopped until the archive is verified. A close running for it ends nothing either, for the same reason in reverse: the wait follows it and reports how it ended. A close that left the session alive failed, and this is the only place left to say so, because the request that asked for it was answered when it was admitted. That reason outlives the wait that started it, on purpose: a close can fail before the next command has even connected, and it is cleared as soon as anything for the session succeeds.
- A stopped or stopping session ends the wait as
stopped, superseding any initialization result that raced with the close request. - A launch failure or failed initialization is reported before a turn; a durable
failed lifecycle ends it as
erroreven after a daemon restart. - Otherwise the wait has a target turn: the caller’s explicit
turn_id, else the turn a create-with-prompt call submitted, else “the newest one”, which additionally requires the session to be idle with an empty queue — with queued prompts, “idle” alone would return an earlier prompt’s outcome. - A capacity outcome with a retry armed is not an ending: the worker will submit the retry itself, so the wait keeps waiting.
A turn that really did fail still reports error: a rejected or interrupted
turn, and an unrecognized stop reason, all come back through the turn record
in rule 3.