Fix: force-complete IsProcessing siblings during client recreation instead of skipping

[Copilot]

When SendAsync fails and triggers client recreation, sibling sessions that are IsProcessing have permanently dead event streams — their CopilotSession was tied to the old client that was just disposed. The re-resume loop was skipping them entirely, leaving recovery to the watchdog (2–5 min delay before orchestrator retries).

Changes

• CopilotService.cs — Replace if (otherState.Info.IsProcessing) continue with ForceCompleteProcessingAsync before re-resume:

// Before: silently skipped, watchdog cleans up 2-5 min later
if (otherState.Info.IsProcessing) continue;

// After (INV-O14): force-complete fires OnSessionComplete immediately,
// then fall through to re-resume on the new client
if (otherState.Info.IsProcessing)
{
    Debug($"[RECONNECT] Sibling '{kvp.Key}' is IsProcessing with dead event stream — force-completing before re-resume");
    try { await ForceCompleteProcessingAsync(kvp.Key, otherState, "client-recreated-dead-event-stream"); }
    catch (Exception forceEx) { Debug($"[RECONNECT] Failed to force-complete sibling '{kvp.Key}': {forceEx.Message}"); }
    // Fall through to re-resume on the new client
}

ForceCompleteProcessingAsync is INV-1-compliant: clears all 9+ companion fields, resolves the TCS, and fires OnSessionComplete — triggering immediate orchestrator retry. The session is then re-resumed on the new client in the same loop iteration.

• MultiAgentRegressionTests.cs — Add ReconnectLoop_IsProcessingSiblings_ForceCompletedNotSkipped (INV-O14) verifying the bare-continue skip pattern is gone and ForceCompleteProcessingAsync is called with the expected reason tag.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• c78vsblobprodcus322.vsblob.vsassets.io
  • Triggering command: /usr/bin/dotnet dotnet restore --no-dependencies /tmp/codeql-scratch-abbd4936ea2bb08e/dbs/csharp/working/55BB33C8E1046D06DB6BC8FB401555C0/missingpackages_workingdir --packages /tmp/codeql-scratch-abbd4936ea2bb08e/dbs/csharp/working/missingpackages /p:DisableImplicitNuGetFallbackFolder=true --verbosity normal --configfile /tmp/codeql-scratch-abbd4936ea2bb08e/dbs/csharp/working/nugetconfig/nuget.config --force (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Bug: IsProcessing siblings skipped during client recreation</issue_title>
<issue_description>When any session SendAsync fails and triggers client recreation, sibling sessions that are currently IsProcessing are skipped during the re-resume loop. Their event callbacks are permanently dead because the old CopilotSession was disposed with the old client.

Root Cause: CopilotService.cs line ~2644 - the re-resume loop skips IsProcessing siblings. The watchdog can only kill stuck sessions, not reconnect them. Result: 2-5 min delay while watchdog times out, then orchestrator retries.

Impact: Low-Medium severity. Orchestrator retries so work is not lost, but causes unnecessary delay.

Proposed Fix: Force-abort the IsProcessing sibling so the orchestrator retries immediately.

Related: Revival path fix (commit e42a357), PR #373 session stability hardening.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Bug: IsProcessing siblings skipped during client recreation #376

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.