Bug: after a session goes cold, the UI follow stream keeps waiting forever — later turns exist on disk but never appear (dsh 0.1.2)

[kiligzzz]

Bug: after a session goes cold (idle dispose), the UI follow stream keeps waiting forever — later turns exist on disk but never appear (dsh 0.1.2 Desktop)

Symptom

On DSH Desktop 2.0.4 (dsh 0.1.2), a session's chat view freezes at the last completed turn. New turns run correctly on the host (verified: user/message/assistant/message/turn/end all appended, seq contiguous, session.list advances), but the Web UI never shows them — it stays pinned on the old turn. Switching sessions and switching back does not recover it. The only recovery is restarting the Desktop app.

Evidence

Timeline from the affected session (Beijing time):

• 21:30 turn 5 completes normally; UI shows it.
• 21:30 → 01:15 the next day: no activity (the session's agent is idle-reaped).
• 01:15 session/end-seed is appended (the cold-restore marker).
• 01:17 user sends a new message → turn 6 runs fully on the host (verified in the session log: 11 messages, seq 45500–51954, complete assistant/message).
• Turns 7, 8, 9 also run fully and durably.
• UI never shows any of them. It stays on turn 5. Forking the session shows all turns fine, so the data is complete.

So this is not a data-loss or read-contract problem: the engine produced everything. The UI-side event stream simply never delivered the post-cold-restore events.

Root cause (traced through the shipped source)

SessionHistoryController.follow (dsh-api-session-controller) listens for session/event and session/created — but not session/disposed:

• When the host session is disposed (idle reaping: detachSession() → emitDisposed), the follow stream is left open and silent.
• The browser's RemoteJournalStream never receives a terminal, so open() stays idempotent (openState === "open" → no-op). Every subsequent "switch session back" reuses the stale stream.
• New turns after cold restore are written by a new session instance, whose events never reach the old stream.

Verified local fix

Make the follow stream terminate when its session is disposed, so the browser detects the end and reconnects (which re-tails the page and rebuilds the window):

// in follow(), alongside the existing session/event and session/created listeners:
const disposeDisposed = this.ctx.on("session/disposed", (session) => {
  if (session.id !== target) return;
  close(); // ends the generator; browser RemoteJournalStream sees terminal → retries → new follow
}, { global: true });

After this patch, a cold session's follow stream closes on dispose, the browser reconnects, and post-restore turns render. Verified working on the released Desktop build.

Relationship to existing discussions

#3631 / #4795 describe a related but distinct defect: a trailing aborted region making the history read path return "no more history". This report is the live-stream counterpart: the stream itself never terminates when the session dies, so even the new turns (which the read path could serve) never reach the UI. Both are the same family — "session lifecycle vs. client stream lifecycle not reconciled" — but the fix locations are different (history read contract vs. follow stream termination).

Environment: DSH Desktop 2.0.4, macOS, dsh 0.1.2.

[liyangbing]

这个现象应与“Session 数据是否已经落盘”分开处理：你给出的 session.list、连续 seq 和 fork 后可见，已经是 Host 写入与 durable replay 的证据；UI 不更新更像 follow stream 的生命周期没有随 session dispose 结束。

建议把复现记录成两条独立时间线：

• Host：dispose 前后的 session/event、session/disposed、turn/end，以及磁盘上最后一个 committed seq；
• Client：follow stream open、terminal/close、retry、重新 tail 的时间点。

在确认之前，不要用“切换 Session”或重复发送 prompt 来测试，因为这可能创建新的 live activation，掩盖旧 stream 是否已经终止。安全的验证顺序是：停止 writer 或正常关闭 Host，复制并哈希 Session 根目录，在副本上确认 list/load/fork；再用同一 build 的干净启动验证新 follow 是否能从 durable tail 追上。若 fork 可见而原页面仍停在旧 turn，应把它报告为 Client stream reconnect 问题，而不是 Session 数据丢失。

handbook 的 Session durability runbook 提供了对应的 writer ownership、冷恢复、fork 与 rollback 证据清单：https://sandbaseai.github.io/deepseek-harness-handbook/session-log-durability.html

这条建议不假设 Desktop 包装器是官方发行版，也不把一次重启视为修复；应继续保留原始日志、Host 版本和 Client stream 时间线。

[argszero]

Verified the full chain against the current tree (cd5ef81 / 0.1.2-alpha.1). Your diagnosis is correct; here is the exact wiring, plus the reconnect mechanism your fix relies on (worth pinning in the PR description).

1. Host side — follow() never terminates on dispose. SessionHistoryController.follow (api/session-controller/src/history.ts:87-169) registers exactly three exit paths: session/event buffering (:105), session/created suffix replay (:110), and signal.abort (:121). There is no session/disposed listener. The generator loop (:150-162) only exits on follower.closed (set by close(), which is called only from the controller's own teardown effect :39-42) or abort — session disposal is neither.

2. session/disposed does fire on detach. detach() → detachEntered (core/session/src/index.ts:940-957) → emitDisposed (:997-1005) when the entry was announced. So the event your fix listens for is real, and it is emitted for idle-reap teardown, not just explicit close.

3. Client side — stale stream, no self-heal. Session client open() is idempotent (openState === 'open' → resolved no-op, client/sessions/session.ts:403); resync() runs only on address replacement (:520), not on stream end. RemoteJournalStream.consume() returns quietly when the iterator ends (client/journal-stream.ts:218-238) — a clean end publishes nothing and triggers no local restart. So after dispose, the browser keeps the dead generation open and silent, exactly as you describe.

4. The reconnect mechanism (your fix's dependency). The RemoteStream generation supervisor (client/remote-stream.ts:99-148) treats a clean generator end after the opening cursor was accepted as ended(true) → new RemoteStreamCarrierError("ended without a terminal result") (:101-102, :127) → carrierFailed callback → waitForRemoteStreamRetry (:136) → a new generation re-invokes follow() with the resume cursor. That is the path by which your close() on dispose makes the browser re-tail: the host generator ending is classified as a retryable carrier loss, not a hard failure, because the opening snapshot was accepted. (A pre-acceptance end would throw a plain Error and become a hard failed() — but a disposed session's follow has long since accepted its opening cursor.)

5. One hygiene note. Your snippet registers the session/disposed listener but the generator's finally block (history.ts:163-168) currently unregisters only the created/event listeners. The dispose listener is controller-lifetime (fine — it filters by session id and is cheap), but if you prefer symmetry, capture its disposer in the same finally. Functionally irrelevant; worth a comment either way.

Net: correct root cause, correct fix location, and the reconnection path is structurally sound in alpha.1. This is the live-stream counterpart of #3631/#4795 (read-path) — the same "session lifecycle vs client stream lifecycle not reconciled" family. Good write-up.