Workers stop when relaunch.sh rebuilds the app mid-orchestration

[PureWeen]

Problem

When a multi-agent worker runs relaunch.sh (or the app is rebuilt/relaunched for any reason), the orchestration loop loses track of the worker. The worker session gets a new SDK session after relaunch, but the orchestrator's SendPromptAndWaitAsync was awaiting the old TCS which gets canceled/orphaned.

Observed behavior

In the PP- IC Things orchestration:

• Worker-1 was dispatched and started doing work
• Worker called relaunch.sh to rebuild PolyPilot with code changes
• After relaunch, the worker's session was restored but the orchestrator never received the completion signal
• The orchestrator's reflection loop hung waiting for a worker result that would never come

Expected behavior

When the app relaunches mid-orchestration:

1. The pending orchestration should be detected and resumed via PendingOrchestration
2. Worker results from before the relaunch should be recoverable
3. OR the orchestrator should detect the relaunch and re-dispatch the worker

Notes

This is related to but distinct from the server idle timeout issue (#396). In this case the app itself is restarted, not just the server killing an idle session.

[github-actions]

✅ Agent Fix completed successfully!

[github-actions]

Pull request created: #823

Generated by Agent Fix

[github-actions]

Fix Summary

Root Cause

Race condition in MonitorAndSynthesizeAsync: After app relaunch, worker sessions are restored as lazy placeholders with Session == null and IsProcessing = false. The InvokeOnUI callback that sets IsProcessing = true is async (queued on UI thread via SynchronizationContext.Post). MonitorAndSynthesizeAsync starts on Task.Run and checks IsProcessing immediately — before the UI callback fires. It sees all workers as idle → collects empty results → aborts orchestration.

Fix

3 changes in CopilotService.Organization.cs:

1. IsWorkerIdleForMonitor() — New method that checks IsSessionStillProcessing(sessionId) (reads events.jsonl from disk) for lazy placeholder workers (Session == null), bypassing the InvokeOnUI race. For connected workers, falls back to the normal !IsProcessing check.

2. Restore completion wait — MonitorAndSynthesizeAsync now waits for IsRestoring to become false + 2s settle time before starting the polling loop, ensuring InvokeOnUI callbacks have fired.

3. Updated idle check — Polling loop uses IsWorkerIdleForMonitor() instead of direct state.Info.IsProcessing check.

Tests

• 10 new unit tests (OrchestrationRelaunchTests.cs): 8 behavioral tests covering all IsWorkerIdleForMonitor scenarios + 2 structural guard tests
• 3 integration test stubs (OrchestrationRelaunchTests.cs in IntegrationTests)
• ✅ All 3680 tests pass (0 failures)

PR & CI

• PR created on branch fix/issue-400-orchestration-relaunch
• Expert review (3-model adversarial) dispatched
• Verify-build (cross-platform) dispatched
• Integration tests (smoke) dispatched

Warning

⚠️ Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• 192.0.2.1

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "192.0.2.1"

See Network Configuration for more information.

Generated by Agent Fix for issue #400 · ● 35.5M · ◷