bug(orchestration): retain mutation reservations after response timeout #926

Activity

1. Juliusolsson05

   added a commit that references this issue on Sep 20, 2026

   fix(orchestration): tell a caller whether its request was ever dispat…

   ...

   1220f43
2. Juliusolsson05

   closed this as completedin 7f485d4on Sep 20, 2026
3. Juliusolsson05 commented on Sep 20, 2026

   

   Juliusolsson05

   on Sep 20, 2026

   OwnerAuthor

   More actions

   Reopening: PR #1077 merged with Fixes #926 on an early commit, but it delivers only the first half of this issue.

   Delivered — "distinguish expired-before-dispatch from outcome-unknown-after-dispatch". sendToWindow now reports whether a renderer actually received the message, because windowForSession resolves through a lease check that deliberately ignores closing while delivery skips a closing window. An undelivered request fails immediately and says it is safe to retry; a dispatched mutation that times out rejects with OrchestrationOutcomeUnknownError, and a late answer is reconciled into main's bookkeeping rather than dropped.

   Not delivered — "retain scoped conflicting-mutation authority until reconciliation". The PR originally did this and review proved it unsound, with probes against the real bridge:

   • The renderer request has no prompt field — the prompt is delivered separately — so two genuinely different fan-out jobs produced a byte-identical key and the second was refused forever. That is the same failure bug(orchestration): one orchestration_create_agent call can spawn two children #952/fix(orchestration): collapse a duplicate create instead of spawning a second child #1069 exists to prevent, one layer down.
   • Nothing could clear a reservation. Listing agents and closing the run both left it in place, and the refusal's own message told the agent to list its agents — so a parent that followed the instruction looped with no legal exit.
   • Its key disagreed with orchestrationCreateAgentCallKey on domain ordering, so the same intent could miss the guard anyway.

   A sound guard has to key on something that can see the prompt, which means it belongs beside createAgentCallOnce at the MCP layer, and it needs a terminating condition — a rendererGeneration bump is proof the answer can never arrive, since a fresh renderer has nothing left to interleave with. Two-step reconciliation, no timer. That is what remains here.
4. Juliusolsson05

   reopened this on Sep 20, 2026
5. Juliusolsson05

   added a commit that references this issue on Sep 20, 2026

   docs(decomposition): record the sweep through 2026-09-20 13:45Z

   ...

   9777c76
6. Juliusolsson05 commented on Sep 20, 2026

   

   Juliusolsson05

   on Sep 20, 2026

   OwnerAuthor

   More actions

   Fixed on main and never closed — the PR carried no Closes trailer.

   7f485d46 fix(orchestration): a timed-out mutation is UNKNOWN, not failed, plus 1220f436 (tell a caller whether its request was ever dispatched).

   This is exactly the distinction the issue asked for. A timed-out read still fails plainly — nothing happened, so ask again. A timed-out mutation keeps its pending entry marked abandoned, records a reservation, and raises OrchestrationOutcomeUnknownError, whose message says the operation may still complete, not to repeat it, and to list the parent's agents first. The acceptance case is the one it was built for: before this, a late answer had nowhere to land (resolve() returns early on an unknown requestId), so a child the renderer really did create became an orphan — running, invisible to its parent — and the caller, told it had failed, reasonably tried again and got two.

   Covered by src/main/orchestration/timeoutOutcome.test.ts.

   Found by cross-referencing open issues against commit messages on main.
7. Juliusolsson05

   closed this as completedon Sep 20, 2026