fix(terminal): stop repeated history refresh replays

[tailong-wu]

Summary

• scope session:needsRefresh SSE frames to the active session
• ignore anonymous SSE backpressure recovery when the active WebSocket already owns the complete terminal stream
• coalesce overlapping refresh fetch/clear/replay cycles per session
• preserve SSE fallback refresh behavior and OpenCode resize recovery

Reproduction

The new regression harness failed in three independent ways on master:

1. a refresh for a background session called _onSessionNeedsRefresh for the active tab
2. an anonymous SSE drain refresh replayed history even while the active terminal WebSocket was complete
3. two refresh signals started two concurrent full-history fetch/replay cycles

Together, sustained terminal output can backpressure the duplicate SSE stream, whose drain signal makes the browser fetch, clear, and replay history. That replay can cause more backpressure and visibly loop old terminal history.

Verification

• npm test (312 files passed, 6097 tests passed)
• npm run typecheck
• npm run lint
• npm run format:check
• npm run check:frontend-syntax
• npm run test:browser -- test/opencode-resize.test.ts -t "does not replay history"

The Playwright regression dispatches both a background-session refresh and an anonymous SSE backpressure refresh with an active terminal WebSocket, then verifies that the page makes zero /terminal history requests.

[Copilot]

🟡 Changes recommended

Add per-request generation or token validation to prevent stale refresh responses from mutating the active terminal.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This pull request prevents repeated terminal history replays by routing refreshes correctly, suppressing duplicate SSE recovery, and coalescing refresh cycles.

Changes:

• Scope refresh events to the active session.
• Avoid redundant SSE recovery when WebSocket output is complete.
• Add concurrency and browser regression coverage.

File summaries

File	Summary
test/terminal-scroll-intent.test.ts	Updates refresh-path assertions.
test/terminal-refresh-routing.test.ts	Adds routing and coalescing tests.
test/opencode-resize.test.ts	Adds browser regression coverage.
src/web/public/app.js	Implements refresh routing and replay locking; a critical stale in-flight request race remains unresolved.

Review details

Suppressed comments (1)

src/web/public/app.js:1869

• _wsReady only says that the current socket is open; it does not prove it received the output that was dropped while a previous socket was reconnecting. During that gap SSE is the fallback, and its anonymous drain frame can arrive after onopen flips _wsReady; returning here then discards the only history-recovery signal, while _connectWs() only sends a resize and does not reload history. Track WS continuity/fallback state (or force one recovery after reconnect) so a drain covering a WS gap is still honored, and add a reconnect-gap regression test.

 if (this._wsReady && this._wsSessionId === this.activeSessionId) return;

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Ark0N]

Thanks for this, and particularly for the regression harness. All three failure modes you describe were real.

They were also fixed on master a few hours before you opened this, by #339, which merged on 2026-08-24 and shipped in 1.23.0. Your branch is based on 9cfd8e8, which predates that merge, and that is where the conflict in app.js comes from. Current master has:

• _onSSENeedsRefresh: if (this._wsReady) return;, which drops every SSE refresh while the WebSocket owns the terminal. Slightly broader than your _wsSessionId === activeSessionId variant.
• _onSessionNeedsRefresh(event = {}) with if (event?.id && event.id !== sessionId) return;, the background-session guard.
• _terminalRefreshOwner, an object-identity single-flight token set before the fetch, re-checked after every await and cleared in finally. selectSession() and _resetAllAppState() null it, so the A -> B -> A case your generation counter targets is covered as well.

So the routing and the coalescing are both already in. The one piece of yours with no equivalent on master is the WebSocket-reopen recovery: recoveredFromGap calling _onSessionNeedsRefresh({ id: sessionId }) after a reconnect, plus zeroing _wsReconnectAttempts in selectSession. That is a different idea from what the title describes, and it makes every reconnect pay for a full clear-and-replay, so I would want it argued and measured on its own rather than carried in on the back of a fix that has already landed.

Closing as superseded. If you still see the replay loop on 1.23.1 please reopen with what you are seeing, and if you want to pursue the reconnect-gap recovery, a small PR against current master making the case for it would be very welcome.