Greptile Summary

This PR repairs the TUI orphaned-streaming-state path: when an inactive final event arrives with no live tracked run in sessionRuns, it now clears the stale activeChatRunId and resets activityStatus to "idle" without surfacing the inactive run's error status or disturbing an overlapping concurrent run. Three regression tests cover the new branch.

One P2 to watch: flushPendingHistoryRefreshIfIdle is invoked earlier in finalizeRun/terminateRun while activeChatRunId is still non-null, so it bails early. After the stale clear nulls activeChatRunId, flushPendingHistoryRefreshIfIdle is never called again — meaning a pendingHistoryRefresh deferred from a prior concurrent local run would remain stuck until the next chat event.

Confidence Score: 4/5

Safe to merge; the orphan-clear logic is correct and well-tested — one P2 edge case around a deferred history refresh not being flushed after stale-clear.

Only P2 findings present. Core logic is sound with three targeted regression tests. The missed flushPendingHistoryRefreshIfIdle call is a niche edge case (orphan final + prior deferred local-run refresh) and doesn't cause data loss or UI corruption.

src/tui/tui-event-handlers.ts — specifically clearStaleStreamingRunIfNoTrackedRunRemains, lines 197–210.

This is a comment left during a code review.
Path: src/tui/tui-event-handlers.ts
Line: 197-210

Comment:
**Stale-clear doesn't flush pending history refresh**

`clearStaleStreamingRunIfNoTrackedRunRemains` sets `activeChatRunId = null` after `flushPendingHistoryRefreshIfIdle` has already been called (and bailed early because `activeChatRunId` was still non-null). If `pendingHistoryRefresh` is `true` from a prior deferred local run, the reload is stuck until the next chat event arrives — and never fires if no further events come in.

This arises when: a local run deferred its history refresh (because a concurrent active run was present), that concurrent run went stale without a tracked final, and then an orphan final triggers the stale-clear path.

Adding `flushPendingHistoryRefreshIfIdle()` after nulling `activeChatRunId` would drain the deferred refresh:

```ts
state.activeChatRunId = null;
setActivityStatus("idle");
clearStreamingWatchdog();
flushPendingHistoryRefreshIfIdle();
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(tui): clear stale streaming after or..." | Re-trigger Greptile}

ProjectClownfish pushed a narrow repair to this branch so the original contributor path can stay canonical.

Source PR: #72389
Validation: pnpm -s vitest run src/tui/tui-event-handlers.test.ts; pnpm check:changed
Contributor credit is preserved in the branch history and PR context.

ProjectClownfish pushed a narrow repair to this branch so the original contributor path can stay canonical.

Source PR: #72389
Validation: pnpm -s vitest run src/tui/tui-event-handlers.test.ts; pnpm check:changed
Contributor credit is preserved in the branch history and PR context.