Switching away from a running session and back stops the view from updating (host keeps producing)

[tanuki-cat]

Summary

Switching away from a session that is actively streaming, then switching back to it, leaves the conversation view frozen at the state it had when I left. The host keeps producing the whole time — the missing output is only missing on the client.

Steps to reproduce

1. Start a turn so a session is actively streaming.
2. Switch to another session.
3. Switch back to the still-streaming session.
4. The view no longer updates. New output never appears.

Reproduces reliably for me.

What makes it clear the host is fine

• Restarting the app recovers the view, and it then shows more tokens than were on screen before the restart. The host had been producing all along; the client simply never received or rendered it.
• Reloading the page also recovers it — but not every time.
• Identical behaviour in a regular browser at http://127.0.0.1:3080 and in a Tauri WKWebView shell, so this is not a webview or rendering-layer issue.

So the host side looks healthy; what does not survive is the client's event subscription for that session across the switch.

Environment

• @deepseek-ai/dsh 0.1.6-alpha.2, web profile
• Node via Homebrew, macOS 26 (arm64)
• ~35 sessions in ~/.dsh/sessions/, 38 MB compressed; largest single session 5.0 MB compressed / 18.2 MB decompressed / 4325 records
• Reproduced both in Firefox and in a WKWebView host

Notes (offered as leads, not as a diagnosis)

I looked through the shipped bundles but could not pin the cause with confidence, so please treat the following as observations only:

• The view sits at openState === "loading" in dsh-client-ui-chat while this happens, i.e. await events.open(...) in SessionController.doOpen has not settled.
• doOpen's catch has if (!isRemoteFailure(error)) throw error before it can set openState = "error". Any error that is not a normalised remote failure is rethrown and the state stays at loading — the user then sees neither a result nor an error. Whatever the root cause turns out to be, this path seems worth tightening: a failure that cannot present itself as a failure is hard to diagnose from the outside.
• SessionEventStream.follow requires assistant-stream revisions to be strictly contiguous and throws RemoteStreamCarrierError on a gap. Carrier errors are swallowed and retried without limit. Since the revision keeps advancing while I am away from the session, I wondered whether the reopened snapshot baseline and the following frames can disagree — but I could not confirm this, and it may well be unrelated.

Happy to collect whatever runtime evidence would help (WS frames, host CPU, logs) — just say what would be useful.

[PerryLink]

The premise I'd correct first: there is no per-session subscription that is supposed to survive the switch. A main-view switch tears the whole Session down and a switch back builds a new one, so what you are looking at is a reopen that never settles — not a subscription that stopped being re-attached.

What actually happens on a switch

replaceMain retains the incoming target as mainView and only then releases the outgoing reference (packages/client/ui-workspace/src/client/navigation.ts:303-333, retain at :309, previous?.release() at :330). When the last reference on a session goes away, the scope is retired (packages/api/session-controller/src/client/sessions/service.ts:555-576, retireScope at :570), which drops the Session instance (service.ts:596-605 → packages/api/session-controller/src/client/sessions/manager.ts:193-199) and disposes its event stream in dispose() (packages/api/session-controller/src/client/sessions/session.ts:570-582). Switching back materializes a fresh Session and runs a fresh doOpen, which constructs a brand-new SessionEventStream (session.ts:587-600). Nothing is re-attached; everything is rebuilt. So "the host kept producing" and "the client shows stale content" are both consistent with the reopen simply never finishing.

Why you can sit at loading forever with no error anywhere

doOpen sets openState = 'loading' at session.ts:588, and only two things move it: success at :604 ('open'), or a caught RemoteFailure at :605-610 ('error'). Note :607:

    } catch (error) {
      if (generation !== this.openGeneration || this.events !== events) return
      if (!isRemoteFailure(error)) throw error

A throw that is not a RemoteFailure escapes doOpen with the state still at loading, and there is no error surfaced to you. Worse for diagnosis, the rejection really is swallowed: the reference constructor does void this.ready.catch(() => {}) (service.ts:195) and the view does not await open(). So "nothing in the console" is not evidence about which cause you have — it is expected in both.

Your third lead does not explain a permanent loading

The revision-contiguity check is real (packages/api/session-controller/src/client/transport.ts:206-215 throws RemoteStreamCarrierError when frame.frame.revision !== expected), and the host side can legitimately produce a revision reset — a replacement Agent restarting at revision 1 resets the accumulator (packages/api/session-controller/src/assistant-stream.ts:38-49), and history.ts:187-191 says outright that later revision resets reach client continuity validation. But a carrier error is a retryable class: RemoteStream calls carrierFailed and reopens, allowing one immediate retry while a Host generation is present (packages/api/gateway/src/client/remote-stream.ts:129-142 and :167-170), and only a second consecutive failure becomes terminal, wrapped as RemoteError('gateway/internal', …) by terminalStreamFailure (remote-stream.ts:206-213). A terminal stream failure lands in failEventStream → openState = 'error' (session.ts:774-784). So a revision gap gives you either recovery or an error state — not a stuck loading.

The one way that path does look like your symptom: while no Host generation is present, the retry waits for the next generation with no timeout at all (remote-stream.ts:171-196). That is an indefinitely pending open with a healthy-looking UI and no error. If that is what you have, the cause is the connection, not the revision check.

What to collect — three observations, in this order

1. DevTools → Network → WS → the dsh socket → Messages. Reproduce, then on the switch back watch for that session. Three distinguishable outcomes:
   • a new follow stream opens and assistant-stream frames keep arriving while the DOM stays frozen → the client is receiving; the stall is downstream in publish/render, not in the subscription;
   • the follow opens but no opening snapshot for that session ever arrives → the open is stuck (the await events.open(...) at session.ts:602, i.e. the host side of the opening never yielded — note the snapshot is only yielded after sourceFor → observeSession resolves, packages/api/session-controller/src/history.ts:178 and :242-252);
   • no new stream for that session at all → the reopen never started, which points at the retain/scope path rather than the stream.
2. Start a different session in the same client while the first is frozen. If a new session streams normally, the connection and gateway are fine and the fault is specific to that session's reopen; if nothing streams, suspect the absent-generation case above.
3. Watch the sidebar row for the frozen session. If its running/activity state keeps updating while the conversation does not, the client is still connected and receiving on other channels — which rules out the connection entirely.

Where I landed

I could not pin a root cause from the source alone, and I would rather say that than hand you a guess. What I can say is what is ruled out: the strict-contiguity revision check cannot by itself produce a permanent loading (it either heals or goes to openState = 'error'), and the freeze is not a subscriber that failed to re-attach, because no subscriber is reused across a switch. The two live candidates are (a) an open that is genuinely still pending — either waiting on an absent connection generation with no timeout, or waiting on a host-side opening that never yielded — and (b) an open that threw a non-RemoteFailure and left the state stuck at loading. Observation 1 separates those two cleanly, and I would not spend more time on the bundles before you have it.

If you can also tell me whether the frozen session's frames stop at exactly the same content you last saw on screen, or at some later point, that further narrows (a) versus (b).