fix(orchestrator): Settle inherited work when provider starts fail#21
What Changed
When a provider cannot be started for a run after its retries run out, or when reopening a session or loading the provider's thread for a restart fails for good, the run and the work it inherited now settle. Pending requests are cancelled, streaming items are finished, and delegated child work tied only to that run is settled, while child threads that are still independently live keep running. Transient start failures still retry and leave the run starting in the meantime.
Settlement is recorded as a durable repair before it runs, and the repair never calls the provider. Server recovery leaves a run that is waiting for repair to that repair instead of interrupting it or starting a provider continuation.
Why
An exhausted start left the run and its inherited work stuck in starting or working states with no path forward, so threads and parent agents waited forever. Recording the repair first means a restart finishes the settlement rather than repeating it or losing it.
Known Limitations
If the server stops after the last start attempt is exhausted but before the repair is recorded, that run can still be left starting after the next launch. The code documents this window; closing it needs the exhaustion and the repair marker to commit together.
Checklist
- This PR is small and focused
- I explained what changed and why
- I included before/after screenshots for any UI changes
- I included a video for animation/interaction changes
Added 1 commit
- fix(orchestrator): Settle inherited work when provider starts failfab2061