Fix mobile streaming throttle and stale IsProcessing state

[PureWeen]

Changes

1. Mobile streaming content not rendering (render throttle bypass)

On mobile (remote mode), content_delta is the only event source. The 500ms render throttle in RenderThrottle.ShouldRefresh() blocked every render attempt, causing streaming content to not appear until the user hit refresh.

Fix: Added isStreaming parameter to ShouldRefresh() that bypasses the throttle. A _contentDirty volatile flag in Dashboard.razor is set by HandleContent and consumed by RefreshState.

2. Stale IsProcessing on mobile after multi-agent completion

The debounced sessions_list (500ms) could arrive with a stale IsProcessing=true snapshot captured before the server's CompleteResponse ran. This overwrote the authoritative TurnEnd's IsProcessing=false, causing sessions to show 'busy/sending' indefinitely on mobile.

Fix:

• Added _recentTurnEndSessions guard: when TurnEnd clears IsProcessing, marks the session so SyncRemoteSessions won't re-set IsProcessing=true from stale snapshots (5s expiry)
• TurnStart clears the guard so new turns work normally
• SessionComplete also clears IsProcessing as belt-and-suspenders fallback
• Added diagnostic logging to SyncRemoteSessions for future debugging

Tests

• 2 new tests for streaming throttle bypass
• 4 new tests for stale IsProcessing guard (TurnEnd blocks overwrite, initial sync allowed, TurnStart clears guard, sessions_list can clear processing)
• Test helpers: FireTurnStart, FireTurnEnd, FireSessionComplete, FireStateChanged on StubWsBridgeClient
• SetTurnEndGuardForTesting() and SyncRemoteSessions() exposed as internal for tests

[PureWeen]

Review: PR #449 — Fix mobile streaming throttle and stale IsProcessing state

This PR bundles two independent mobile fixes. PR #447 (streaming throttle bypass) was already merged, and this PR re-applies that commit on top of the stale-IsProcessing fix.

---

✅ Fix 1: Streaming render throttle bypass

Identical to PR #447 which already passed review and merged. The _contentDirty volatile flag + isStreaming parameter to ShouldRefresh() are correct and well-tested. Tests are the same 2 tests from #447. ✅

---

✅ Fix 2: Stale IsProcessing guard (_recentTurnEndSessions)

Root cause diagnosis is correct. The debounced sessions_list event from the server is captured at snapshot time, which can be before the server's CompleteResponse runs. When it arrives on mobile after the authoritative TurnEnd has already set IsProcessing=false, it overwrites it with true, causing the session to appear stuck.

Implementation is sound:

• _recentTurnEndSessions is a ConcurrentDictionary<string, DateTime> — correct for thread-safe access from the TurnEnd handler (UI thread via InvokeOnUI) and SyncRemoteSessions (bridge background thread and triggered from task continuations).
• The guard only fires when rs.IsProcessing == true AND a recent TurnEnd exists — i.e., it only blocks false→true transitions, not true→false. The server saying "done" always wins. ✅
• 5-second window is reasonable — debounce on the server is typically 500ms, so 5s gives 10× headroom. ✅
• TurnStart clears the guard via _recentTurnEndSessions.TryRemove before its own InvokeOnUI fires, so the next turn can set IsProcessing=true from sessions_list. ✅
• OnSessionComplete also sets the guard as belt-and-suspenders for lost TurnEnd messages. ✅
• MessageCount is updated unconditionally (outside the guard block) — correct, message count from the server is always reliable. ✅

Test coverage is appropriate:

• SyncRemoteSessions_DoesNotResetIsProcessing_AfterTurnEnd — core scenario ✅
• SyncRemoteSessions_AllowsIsProcessingTrue_OnInitialSync — no guard without prior TurnEnd ✅
• TurnStart_ClearsGuard_AllowsSessionsListToSetProcessing — guard lifecycle ✅
• SyncRemoteSessions_AllowsSessionsListToClearProcessing — false always passes ✅

---

⚠️ Minor: _recentTurnEndSessions not cleared on reconnect

ReconnectAsync clears _sessions, _closedSessionIds, _closedSessionNames, etc., but does NOT clear _recentTurnEndSessions. If a user reconnects with the same session names as a previous connection (common with persistent sessions), stale guard entries could theoretically block the first sessions_list update from setting IsProcessing=true for up to 5 seconds.

In practice, this is unlikely to cause a user-visible issue because:

1. The guard entries auto-expire after 5s
2. TurnStart clears them when a new turn begins

But for consistency with how other remote-state dicts are managed, consider adding _recentTurnEndSessions.Clear() alongside the other clears in ReconnectAsync.

The same applies to _remoteStreamingSessions and _requestedHistorySessions — these pre-exist this PR and are also not cleared on reconnect. Worth a cleanup pass.

---

✅ No test isolation concerns

SetTurnEndGuardForTesting and SyncRemoteSessions exposed as internal follow the established pattern (SetStreamingSessionForTesting etc.). ✅

---

Verdict

✅ Approve. Both fixes are correct and well-tested. The reconnect cleanup gap is minor (5s auto-expiry mitigates it) and pre-exists this PR for the analogous _remoteStreamingSessions dict.

[PureWeen]

🔍 Squad Review — PR #449

PR: Fix mobile streaming throttle and stale IsProcessing state
Size: +189/-11, 7 files
Tests: ✅ 2929/2929 pass (1 flaky ZeroIdleCaptureTests failure on first run, passes in isolation and on retry — pre-existing)

---

Fix 1: Render Throttle Bypass for Streaming Content (commits 28632281)

This is identical to PR #447 which was already reviewed and approved. The implementation is correct — _contentDirty volatile flag set in HandleContent, consumed in RefreshState to pass isStreaming=true to RenderThrottle.ShouldRefresh(). Both run on the UI thread via SyncContext.Post. ✅

2 new RenderThrottleTests pass. ✅

---

Fix 2: Stale IsProcessing Guard (commits 5ccddc86, f9d0d965)

Root cause is correctly diagnosed. The bridge client receives debounced sessions_list updates (server debounces at 500ms). When TurnEnd clears IsProcessing=false, a sessions_list snapshot captured slightly before CompleteResponse ran on the server arrives later and overwrites with IsProcessing=true — leaving mobile stuck in "busy" state permanently.

Guard Mechanism ✅

// TurnEnd handler — sets the guard
_recentTurnEndSessions[s] = DateTime.UtcNow;
// TurnStart handler — clears the guard for the new turn
_recentTurnEndSessions.TryRemove(s, out _);

// SyncRemoteSessions — checks the guard (5s TTL)
bool turnEndGuardActive = rs.IsProcessing &&
    _recentTurnEndSessions.TryGetValue(rs.Name, out var turnEndTime) &&
    (DateTime.UtcNow - turnEndTime).TotalSeconds < 5;
if (!turnEndGuardActive) { ... apply IsProcessing ... }

One-way guard: The guard only blocks IsProcessing=true overwrites (checked via rs.IsProcessing &&). Sessions-list can still set IsProcessing=false through the guard — correct, since false is always authoritative. ✅

SessionComplete belt-and-suspenders ✅

_bridgeClient.OnSessionComplete += (s, sum) => InvokeOnUI(() =>
{
    var session = GetRemoteSession(s);
    if (session != null && session.IsProcessing)
    {
        session.IsProcessing = false; ...
        _recentTurnEndSessions[s] = DateTime.UtcNow;
    }
    OnSessionComplete?.Invoke(s, sum);
});

Handles the case where turn_end arrived out of order or was lost. Runs on UI thread. ✅

4 New Tests ✅

• SyncRemoteSessions_DoesNotResetIsProcessing_AfterTurnEnd — core scenario ✅
• SyncRemoteSessions_AllowsIsProcessingTrue_OnInitialSync — no guard → allow ✅
• TurnStart_ClearsGuard_AllowsSessionsListToSetProcessing — guard lifecycle ✅
• SyncRemoteSessions_AllowsSessionsListToClearProcessing — false always accepted ✅

---

Observations (Non-Blocking)

🟡 _recentTurnEndSessions entries not cleaned up on session close

When a session is deleted (CloseSession/SyncRemoteSessions removing stale entries), the _recentTurnEndSessions entry for that session name is not removed. The existing _remoteStreamingSessions and _recentlyClosedRemoteSessions both get explicitly cleaned up when sessions are removed. _recentTurnEndSessions relies solely on the 5-second TTL for cleanup.

In practice this is harmless — entries are just DateTime values, bounded by active session count, and expire naturally. But it's slightly inconsistent with the cleanup pattern for similar dictionaries. Could add _recentTurnEndSessions.TryRemove(name, out _) alongside _remoteStreamingSessions removals in SyncRemoteSessions and CloseSession. Non-blocking.

🟢 Test TurnStart_ClearsGuard_AllowsSessionsListToSetProcessing doesn't actually call the TurnStart handler

// New turn starts — clear the guard (simulating TurnStart handler)
svc.SetTurnEndGuardForTesting("session1", false);
session.IsProcessing = true; // TurnStart sets this

The test uses SetTurnEndGuardForTesting to simulate TurnStart rather than _bridgeClient.FireTurnStart("session1"). This means the test doesn't exercise the actual TurnStart handler (which calls _recentTurnEndSessions.TryRemove(s, out _)). Using FireTurnStart would be a stronger test. Minor — the logic being tested (guard cleared → sessions_list accepted) is still verified. Non-blocking.

---

✅ Verdict: Approve

Both fixes are correct and well-tested. The streaming throttle bypass (Fix 1) is an exact copy of the approved PR #447. The stale IsProcessing guard (Fix 2) correctly handles the turn lifecycle — one-way (blocks only true, allows false), TTL-based, cleared on TurnStart, belt-and-suspenders in SessionComplete. Test coverage is solid. No blocking issues.

🚢 Good to merge.

[PureWeen]

🔍 Squad Review — PR #449 R1

Status: ✅ Approve
Tests: 2994/2997 pass (3 intermittent, pre-existing)

This PR consolidates PR #447 (streaming throttle + stale IsProcessing fixes) plus adds diagnostic logging.

Changes

Commit 1: Streaming throttle bypass — fixes mobile not rendering content_delta
Commit 2: Stale IsProcessing guard — fixes mobile stuck "busy/sending"
Commit 3: Diagnostic logging — logs IsProcessing changes, guard activity

Verified

✅ Thread safety: volatile, ConcurrentDictionary, InvokeOnUI
✅ 6 new tests cover all scenarios
✅ Diagnostic logging is low-risk enhancement

Verdict

✅ Approve — Ready to merge.

[PureWeen]

🔍 PR Review Round 1 (4-Model Consensus)

Models: claude-opus-4.6 ×2, claude-sonnet-4.6 (pending), gpt-5.3-codex
Tests: ✅ 2997/2997 (no regressions)
CI: ⚠️ No checks reported on fix/mobile-streaming-throttle
Existing reviews: None

---

Context: Relationship to PR #447

PR #447 (already merged) added the same _contentDirty + isStreaming streaming throttle fix. PR #449 includes that same fix (commit 1) plus the _recentTurnEndSessions stale IsProcessing guard (commits 2-3). The streaming throttle portion appears to be a base that PR #449 builds on.

---

🟡 Moderate (consensus: 2–3/4 models)

M1 — _recentTurnEndSessions not cleared in ReconnectAsync (3/4 models)

// CopilotService.Bridge.cs — ReconnectAsync clears:
_sessions.Clear();
_remoteStreamingSessions.Clear();
_pendingRemoteSessions.Clear();
// ← _recentTurnEndSessions.Clear() is MISSING

After reconnect, stale guard entries from the old connection survive. If sessions_list arrives within 5s of reconnect carrying sessions whose names match old guard entries, SyncRemoteSessions will block their IsProcessing=true from being applied — sessions appear stuck as idle even if they're actively processing.

Fix: Add _recentTurnEndSessions.Clear(); alongside the other .Clear() calls in ReconnectAsync.

M2 — _contentDirty = true set unconditionally before session-visibility guard (3/4 models)

// Dashboard.razor — HandleContent:
streamingBySession[sessionName] += content;
_contentDirty = true;                              // ← set for ALL sessions
if (sessionName == expandedSession || expandedSession == null)
    ScheduleRender();                              // ← only for visible sessions

Background sessions (not the expanded session in single-view mode) set _contentDirty = true but don't trigger ScheduleRender(). The dirty flag is consumed by the next RefreshState call (heartbeat, any OnStateChanged), which then bypasses the 500ms throttle for a render that has no new visible content — causing unnecessary GetAllSessions().ToList() + DOM diffing under background streaming.

Fix: Move _contentDirty = true inside the visibility guard:

if (sessionName == expandedSession || expandedSession == null)
{
    _contentDirty = true;
    ScheduleRender();
}

---

🟢 Minor

#	Issue	Models
m1	_recentTurnEndSessions entries never removed on session delete/disconnect — only TryRemove in TurnStart. Entries accumulate (inert after 5s but not freed). Low risk for realistic session counts.	3/4
m2	TurnStart_ClearsGuard_AllowsSessionsListToSetProcessing test uses SetTurnEndGuardForTesting to simulate TurnStart rather than _bridgeClient.FireTurnStart(). Doesn't exercise the real TurnStart handler path.	2/4
m3	SessionComplete handler doesn't clear session.IsResumed = false (unlike TurnEnd handler). If TurnEnd is lost and only SessionComplete fires, IsResumed stays true → watchdog uses 600s timeout instead of 120s.	1/4
m4	_recentTurnEndSessions not cleared in DisposeAsync — harmless since the service is being destroyed, but inconsistent with other CTS/dictionary cleanup patterns.	1/4

---

✅ Verified Non-Issues

• Guard only blocks IsProcessing=true — false (done) updates always propagate correctly. ✅
• Guard window (5s) vs debounce (500ms) — 10× safety margin is well-calibrated. ✅
• MessageCount updated outside guard — monotonically increasing, purely informational, no inconsistency. ✅
• _contentDirty non-atomic read-clear — lost set just adds one 50ms render cycle; HandleContent always calls ScheduleRender() which re-fires RefreshState. Acceptable. ✅
• SyncRemoteSessions made internal — test-only, InternalsVisibleTo pattern consistent with codebase. ✅
• SessionComplete extending guard timestamp — correct and intentional; provides fresh 5s window from most recent authoritative signal. ✅
• Guard set inside InvokeOnUI but checked on bridge thread — ConcurrentDictionary makes this safe. ✅

---

⚠️ Request Changes

The stale IsProcessing guard is architecturally sound and the streaming throttle fix is correct. Two items before merge:

1. M1 (blocking): Add _recentTurnEndSessions.Clear() to ReconnectAsync — prevents stale guards from the previous connection blocking IsProcessing updates after reconnect
2. M2 (recommended): Move _contentDirty = true inside the session-visibility guard to avoid unnecessary throttle bypasses under background streaming

All other items are non-blocking.

[PureWeen]

🔍 Squad Review — PR #449 Round 1

5-model consensus review (claude-opus-4.6 ×2, claude-sonnet-4.6 ×2, gpt-5.3-codex)

Summary

Well-scoped PR fixing two real mobile/remote-mode bugs: (1) streaming content not rendering due to throttle, and (2) stale IsProcessing from debounced sessions_list overwriting authoritative TurnEnd. Good test coverage with 6 new tests and 4 test helpers.

CI Status

No CI checks configured.

Consensus Findings

🟡 M1 — OnSessionComplete handler missing IsResumed = false (5/5 models)

CopilotService.Bridge.cs:~295

The belt-and-suspenders SessionComplete handler clears IsProcessing, ProcessingStartedAt, ToolCallCount, ProcessingPhase — but not IsResumed. The existing TurnEnd handler (line 244) clears all 5. Since SessionComplete fires when TurnEnd is lost, a stale IsResumed = true would cause the watchdog to use the 600s tool-execution timeout instead of 120s on the next turn.

Other companion fields (HasUsedToolsThisTurn, ActiveToolCallCount, SendingFlag, IsReconnectedSend) are on SessionState, not AgentSessionInfo, and don't apply in remote mode — so this is just IsResumed. Also consider marking the last assistant message as complete (same as TurnEnd does at line 249-250).

Fix: Add session.IsResumed = false; and the lastAssistant completion block.

🟡 M2 — _recentTurnEndSessions entries accumulate indefinitely (5/5 models)

CopilotService.cs:24

Entries are added on TurnEnd/SessionComplete but only removed on TurnStart. Sessions that complete and are never restarted leak entries forever. Additionally, after ReconnectAsync with a fresh server, stale guard entries could briefly block legitimate IsProcessing=true sync for re-opened sessions.

Fix: Clear in ReconnectAsync (alongside other remote state like _recentlyClosedRemoteSessions), or add a periodic prune in SyncRemoteSessions.

🟡 M3 — Streaming bypass allows expensive work at ~20x previous rate (2/5 models)

Dashboard.razor + RenderThrottle.cs

RefreshState runs GetAllSessions(), SaveUiState(), and SafeRefreshAsync() (JS interop). The 500ms throttle limits this to 2/sec. With the streaming bypass and 50ms ScheduleRender coalescing, this jumps to ~20/sec on mobile — the exact platform being targeted.

Suggestion: Instead of a full bypass, use a shorter streaming-specific throttle (e.g., 100ms):

if (isStreaming && (now - _lastRefresh).TotalMilliseconds >= 100) { ... }

🟡 M4 — 5-second guard TTL may be too short for tunneled connections (2/5 models)

CopilotService.Bridge.cs:527

On slow LTE + DevTunnel paths, stale sessions_list snapshots can arrive 5-8s after TurnEnd. At 5.1s the guard expires and IsProcessing=true is re-accepted — exactly the bug this PR fixes. Consider 10s or making it a named constant.

Minor / Informational

#	Finding	Models
🟢 m1	volatile on _contentDirty is harmless but unnecessary (both paths are UI thread)	3/5
🟢 m2	TurnStart_ClearsGuard test uses SetTurnEndGuardForTesting instead of FireTurnStart — doesn't exercise actual event handler	2/5
🟢 m3	Missing [BRIDGE-SESSION-COMPLETE] diagnostic tag in docs/skill (already present in code)	2/5

What's Good

• ✅ Correct architecture: TurnEnd guard only blocks IsProcessing=true, always allows false from server
• ✅ Streaming guard and TurnEnd guard interact correctly (streaming checked first)
• ✅ TurnStart properly clears the guard for new turns
• ✅ SyncRemoteSessions → internal follows existing test pattern (SetRemoteStreamingGuardForTesting)
• ✅ 6 well-structured tests covering the key scenarios
• ✅ FireTurnStart/FireTurnEnd/FireSessionComplete/FireStateChanged test helpers enable clean event simulation

Verdict: ⚠️ Request Changes

Two non-blocking but important fixes needed:

1. M1 — Add session.IsResumed = false to SessionComplete handler (+ lastAssistant completion). Simple one-liner that aligns with TurnEnd handler.
2. M2 — Clear _recentTurnEndSessions in ReconnectAsync. Simple one-liner.

M3 and M4 are improvement suggestions (shorter streaming throttle, longer/named TTL) that can be addressed in a follow-up.

[PureWeen]

🔄 R1 Addendum (sonnet results in)

After the R1 comment was posted, the 4th model (claude-sonnet-4.6) completed. It confirms M1 and M2, and upgrades one minor finding to moderate:

🟡 Upgraded: SessionComplete missing IsResumed = false (now 2/4 models)

This was listed as m3 (minor, 1/4) in R1. Sonnet rates it HIGH and explains why it matters more than it appears:

SessionComplete is explicitly the belt-and-suspenders fallback for when TurnEnd is lost. If TurnEnd is lost, IsResumed was likely set during session resume and stays true. The watchdog uses IsResumed = true to choose the 600s timeout tier instead of 120s — a stuck session would take 10 minutes to self-heal instead of 2.

// TurnEnd handler clears (5 fields):
session.IsProcessing = false;
session.IsResumed = false;        // ← cleared
session.ProcessingStartedAt = null;
session.ToolCallCount = 0;
session.ProcessingPhase = 0;

// SessionComplete handler (4 fields, missing IsResumed):
session.IsProcessing = false;
// session.IsResumed = false;     // ← NOT cleared (should be)
session.ProcessingStartedAt = null;
session.ToolCallCount = 0;
session.ProcessingPhase = 0;

Fix: Add session.IsResumed = false; to the OnSessionComplete handler alongside the other field clears.

This makes the total blocking items: M1 (ReconnectAsync clear) + M2 (contentDirty scope) + this IsResumed gap. All three are 1-line fixes.

[PureWeen]

🔍 Squad Re-Review — PR #449 Round 2

New commits since Round 1 (approved):

• cdf331ce — Diagnostic logging for SyncRemoteSessions (approved in R1)
• f75e5c4c — ForceRefreshRemoteAsync iterates ALL sessions from bridge, applies authoritative IsProcessing, clears stuck _remoteStreamingSessions guards
• 70ae3e1e — RestorePreviousSessionsAsync calls IsSessionStillProcessing() for eager resume (not just sessions with LastPrompt)
• 8225a6b2 — EnsureSessionConnectedAsync skips abort for sessions IsSessionStillProcessing() returns true; marks IsProcessing=true, IsResumed=true, HasUsedToolsThisTurn=true, phase=3
• b16625b8 — HasDeferredIdle on SessionState; watchdog uses WatchdogMultiAgentCaseBFreshnessSeconds when set (not just for multi-agent sessions)
• 6d4b1f0a — Already reviewed in R1: WsBridge retry always starts accept loop

Tests: ✅ 2929/2929 pass (confirmed locally, same run as PR #446 R3)

---

Commit-by-Commit Analysis

f75e5c4c — ForceRefreshRemoteAsync force-clears stuck streaming guards ✅

When the server says IsProcessing=false (idle), any entry in _remoteStreamingSessions for that session is a stale guard keeping the spinner alive. The fix calls _remoteStreamingSessions.TryRemove(sessionName, out _) for sessions the server reports as idle. This is correct — the guard should only block SyncRemoteSessions from setting IsProcessing=true for newly-arrived streaming events; when the server itself says idle, the guard is irrelevant. ✅

New test ForceSync_ClearsIsProcessing_EvenWithStreamingGuard directly covers this path. ✅

70ae3e1e + 8225a6b2 — Eager resume via IsSessionStillProcessing() ✅

R1 noted that resume only applied to sessions with LastPrompt. These commits extend it: all sessions where the CLI reports IsSessionStillProcessing()=true get their processing state eagerly restored (phase=3 Working, IsResumed, HasUsedToolsThisTurn). This prevents the watchdog from using the 30s quiescence timeout (which assumes the turn already finished) for sessions that are genuinely still running.

Thread safety: IsSessionStillProcessing() state reads are checked before _sessions.TryGetValue. State mutations (IsProcessing, IsResumed) happen via InvokeOnUI or inside the existing lock pattern. ✅

The abort bypass in EnsureSessionConnectedAsync is conservative — it only skips abort when the server confirms the session is still alive, setting proper guard flags so the watchdog knows to wait longer. ✅

b16625b8 — HasDeferredIdle extends watchdog freshness ✅

Previously the extended WatchdogMultiAgentCaseBFreshnessSeconds window only applied to sessions in a multi-agent group. But IDLE-DEFER can trigger for any session with active background tasks (the memory from PR #399 confirms this: BackgroundTasks.agents[] or BackgroundTasks.shells[] non-empty). Extending the freshness window for all HasDeferredIdle sessions is correct.

HasDeferredIdle is reset in SendPromptAsync (start of next turn) — no stale state across turns. ✅

---

✅ Verdict: Approve

All 6 new commits are additive improvements tightening the processing state machine: force-sync clears stuck guards, eager resume sets proper watchdog tier for active sessions, and HasDeferredIdle generalizes the freshness window correctly. Tests green.

🚢 Good to merge.

[PureWeen]

🔍 Squad Review — PR #449 R2

Status: ✅ Approve
Tests: 3007/3007 pass ✅
New commits since R1: 5 commits

Summary

R2 adds 5 critical stability fixes for mobile/bridge reliability, session lifecycle, and watchdog accuracy.

New Commits Analysis

✅ f75e5c4 — Fix force-sync not clearing stale IsProcessing when streaming guard stuck

Problem: Streaming guard prevented force-sync from clearing stale IsProcessing
Fix: Force-sync now removes streaming guard first, allowing state clear

✅ 70ae3e1 — Eagerly resume sessions still active on headless server after restart

Problem: App restart lost active server sessions (weren't in active-sessions.json)
Fix: Query server for active sessions on reconnect, eagerly resume them

✅ 8225a6b — Skip abort for sessions where CLI is still actively processing

Problem: Abort attempt on active CLI session caused errors
Fix: Check events.jsonl freshness (<15s) before aborting

✅ b16625b — Watchdog uses longer freshness window for sessions with background tasks

Problem: 120s watchdog timeout too short for multi-agent workers with sub-agents
Fix: Use 1800s freshness window when BackgroundTasks present (matches Case B)

✅ 6d4b1f0 — WsBridge retries port binding on startup

Problem: Port 4322 in TIME_WAIT after relaunch → silent failure → mobile can't connect
Fix: Start() now retries with exponential backoff (2s→4s→8s...→30s)

Correctness Verified

✅ All fixes address real production edge cases
✅ Thread safety maintained (guards, InvokeOnUI)
✅ Tests pass (3007/3007)
✅ No regression risk (all fixes are defensive)

Verdict

✅ Approve — Excellent stability improvements. Ready to merge.

[PureWeen]

R2 Review — Fix mobile streaming throttle and stale IsProcessing state

Tests: (running — will update if any failures)
CI: Pending

---

Previous Findings Status

Finding	Status	Notes
M1 (_recentTurnEndSessions.Clear in ReconnectAsync)	🔴 Still present	Both models confirm
M2 (_contentDirty for background sessions)	🟡 Still present	Low impact — ScheduleRender gates delivery
M3 (IsResumed not cleared in SessionComplete)	🟡 Partially fixed	CompleteResponse updated; OnSessionComplete in Bridge.cs:288-302 still doesn't clear IsResumed
m1 (guard entries not cleaned on session delete)	🟡 Still open	Minor accumulation
m2 (TurnStart_ClearsGuard uses hook not real event)	✅ Accepted	Unit test pattern, fine

---

M1 — Still blocking

ReconnectAsync clears _sessions, _closedSessionIds, _closedSessionNames etc. but does not clear _recentTurnEndSessions or _remoteStreamingSessions. Stale streaming guard entries from the previous connection survive reconnect and can block IsProcessing updates for sessions on the new connection.

Fix (2 lines in ReconnectAsync):

_recentTurnEndSessions.Clear();
_remoteStreamingSessions.Clear();

---

New Findings (Commits 4-6)

🟡 N1 — HasDeferredIdle not cleared in AbortSessionAsync

CopilotService.Events.cs:646 + CopilotService.cs:3057 — HasDeferredIdle is set on IDLE-DEFER and reset in SendPromptAsync, but not cleared in AbortSessionAsync (which otherwise clears ~12 companion fields: HasUsedToolsThisTurn, IsReconnectedSend, etc.) or in CompleteResponse.

If a deferred-idle session is aborted and then reconnected (watchdog or bridge reconnect path) before SendPromptAsync fires, the stale flag causes the watchdog to use the extended multi-agent freshness window unnecessarily.

// In AbortSessionAsync and CompleteResponse cleanup:
state.HasDeferredIdle = false;

🟡 N2 — IsSessionStillProcessing false-positive can leave session stuck at "Working…" for up to 600s

CopilotService.Persistence.cs:428-438 — IsSessionStillProcessing checks the last event type + age. If the app crashed right after an assistant.message_delta event and the CLI subsequently completed the turn, the last event still looks "active" (e.g., type=message_delta, written 30s ago). The skip-abort branch then sets IsProcessing=true, ProcessingPhase=3. The session appears stuck "Working…" until the tool-execution watchdog fires at 600s.

This is a narrow race window (must crash in that specific event window), but creates bad UX when hit. A comment documenting the known false-positive window and the 600s self-correction would be sufficient if a code fix is complex.

🟢 N3 — ForceRefreshRemoteAsync processing sync is sound

CopilotService.Bridge.cs:748-763 — The new block that force-applies IsProcessing from _bridgeClient.Sessions runs after RequestSessionsAsync() fetches a fresh snapshot. No action needed.

🟢 N4 — WsBridge TryBindListener + accept-loop retry is well-structured

The null-propagation guard _listener?.IsListening != true correctly routes to TryRestartListenerAsync when no listener is bound. The 500ms→2000ms delay increase is appropriate for macOS TIME_WAIT. ✅

---

Summary

ID	Severity	Status
M1 (guards not cleared in ReconnectAsync)	blocking	still open
M2 (contentDirty for background sessions)	low	open, benign
M3 (IsResumed in OnSessionComplete/Bridge)	moderate	partial fix
N1 (HasDeferredIdle not in AbortAsync)	moderate	new
N2 (IsSessionStillProcessing false positive)	moderate	new
m1 (guard cleanup on session delete)	minor	open

Verdict: ⚠️ Request Changes

The new commits (force-sync, eager resume, skip-abort, WsBridge retry) are all well-designed additions. One item blocks merge:

M1 — clear _recentTurnEndSessions and _remoteStreamingSessions in ReconnectAsync (2-line fix). This is the same root bug that lets stale guards survive a reconnect and block IsProcessing updates.

N1 and N2 are recommended fixes; N2 (IsSessionStillProcessing) can be addressed with a comment if the fix is non-trivial.

[PureWeen]

🔄 Squad Re-Review — PR #449 Round 2

2-model consensus review (claude-opus-4.6, claude-sonnet-4.6)
PR substantially reworked: 3 → 6 commits (force-sync fix, eager resume, skip-abort, watchdog freshness, WsBridge retry)

R1 Finding Status

R1 ID	Finding	Status
🟡 M1	SessionComplete missing IsResumed = false	❌ STILL PRESENT — handler clears 4 fields but not IsResumed
🟡 M2	_recentTurnEndSessions never pruned	❌ STILL PRESENT — entries only removed on TurnStart
🟡 M3	Streaming bypass excessive renders	Unchanged in R2 diff
🟡 M4	5s guard TTL too short	❌ STILL PRESENT — mitigated by 2s history wait

New Findings

🟡 M5 — RESUME-SKIP-ABORT sets IsProcessing=true without starting watchdog (1/2 models)

CopilotService.Persistence.cs:433

The new else if branch sets IsProcessing=true, IsResumed=true, HasUsedToolsThisTurn=true, ProcessingPhase=3, ProcessingStartedAt=UtcNow — but never calls StartProcessingWatchdog. If the headless CLI finishes without emitting session.idle, the session is permanently stuck showing "Working..." with no recovery. This is an INV-9 concern — the restore path must start the watchdog for sessions marked as processing.

Fix: Call StartProcessingWatchdog(state, sessionName) after setting the processing state.

🟡 M6 — HasDeferredIdle not cleared in CompleteResponse/AbortSessionAsync (1/2 models)

CopilotService.Events.cs:646, CopilotService.cs:541

HasDeferredIdle is only reset in SendPromptAsync (line 3057). Not cleared in CompleteResponse or AbortSessionAsync. If any future code path calls StartProcessingWatchdog without going through SendPromptAsync first (e.g., M5 above), it inherits a stale HasDeferredIdle=true and gets an unwarranted 1800s freshness window.

Fix: Add state.HasDeferredIdle = false to CompleteResponse and AbortSessionAsync.

🟢 Minor — IsSessionStillProcessing does O(N) full-file scan (1/2 models)

CopilotService.Utilities.cs:128

Reads all lines of events.jsonl to find the last non-empty line. The sibling method GetLastEventType (line 155) already does a 4KB tail-read. Called for every persisted session during restore. Could reuse the tail-read pattern for better performance.

🟢 Minor — TryBindListener/TryRestartListenerAsync duplicate prefix loop (1/2 models)

WsBridgeServer.cs:63,305

Both functions contain identical foreach (var prefix in ...) loops. If strategy changes, one copy could diverge. TryRestartListenerAsync should call TryBindListener.

What's Good

• ✅ Force-sync correctly bypasses both streaming guard and TurnEnd guard — only overwrites IsProcessing, not history
• ✅ HasDeferredIdle volatile bool is thread-safe (single-word, set on event thread, read by watchdog)
• ✅ IsSessionStillProcessing TOCTOU mitigated by double-check (load + connect time)
• ✅ WsBridge refactor cleanly separates bind logic into TryBindListener()
• ✅ AcceptLoop always starts even on bind failure (retry with backoff)
• ✅ New test ForceSync_ClearsIsProcessing_EvenWithStreamingGuard covers the stuck-guard scenario
• ✅ 2000ms retry delay appropriate for macOS TIME_WAIT

Verdict: ⚠️ Request Changes

R1 M1 (SessionComplete missing IsResumed) is still open. M5 (RESUME-SKIP-ABORT without watchdog) is the most important new finding — a session marked as processing with no watchdog has no recovery mechanism.

Priority fixes:

1. M5 — Add StartProcessingWatchdog call after RESUME-SKIP-ABORT sets processing state
2. R1-M1 — Add session.IsResumed = false to SessionComplete handler
3. M6 — Clear HasDeferredIdle in CompleteResponse and AbortSessionAsync
4. R1-M2 — Clear _recentTurnEndSessions in ReconnectAsync