Desktop 0.2.0-rc.2: switching sessions permanently blanks the 「对话 / Conversation」 pane (empty transcript, does not self-heal)

[TTflysky]

Summary

On the Windows desktop client @deepseek-ai/dsh-desktop/0.2.0-rc.2, the first session rendered after a (re)load is fine, but every session switch afterwards leaves the Conversation pane completely empty (transcript node count = 0) and the state never self-heals — it poisons all subsequent sessions until the whole renderer is restarted. The Trajectory (轨迹) tab keeps working for the same session.

I originally suspected my own data (I had repaired/rebuilt some session logs), so I validated everything before reporting: all 74 sessions pass DSH's own four validators, and the behaviour reproduces with a vanilla plugin set. It is a client-side defect in the session-switch path, and it is worth fixing because a user who happens to hit it cannot read any conversation at all.

Environment

• @deepseek-ai/dsh-desktop/0.2.0-rc.2 (built 2026-09-29), Electron 44 / Chrome 152, Windows x64
• Update channel nightly (feed reports 0.2.0-rc.2 as latest, so this is the current nightly)
• Diagnostics done over CDP (--remote-debugging-port=9222)

Reproduction

1. Start the desktop app; the Conversation pane renders the current session correctly.
2. Click any other session in the sidebar.
3. The Conversation pane becomes empty (only a "load earlier" affordance remains).
4. Switch back to the first session — still empty.
5. Switch to any third session — still empty.
6. Waiting 130+ seconds does not help.
7. Restart the app: it renders again — until the next switch, when it breaks again.

Measured state (CDP)

Stage	[data-chat-flow] children	[data-slot="conversation.chat.node"]
First session after reload/boot	73–138	138–220 ✅
After switching to another session	1 (only "load earlier")	0 ❌
After switching back	1	0 ❌
130 s after the switch	1	0 ❌

In the broken state the client's own session store still reports openState: "open", openError: null, blank: false, hasMore: true — i.e. the client believes the session is fine while the transcript node list is empty.

Ruled out (each with evidence)

• Session data corruption — 74/74 sessions pass assertV4RowAdmission, assertReleasedV4Relationships, adoptSessionEvent and Session.fromRestore.
• Third-party plugins — still blank with all 13 third-party client plugins removed; all 86 client modules load successfully.
• Layout / zero-height — in the healthy state [data-chat-flow] measures 696×9015 with display:flex, visibility:visible, opacity:1; resizing the window does not restore content in the broken state.
• Host not sending data — an actual session/follow response was captured: {"type":"snapshot","cursor":2515,"records":[ …275 events… ],"projections":["asOfSeq","values"]}.
• JS exceptions — a permanently installed window.onerror / unhandledrejection reporter plus CDP Log.entryAdded capture recorded zero real errors (only unrelated 404s for third-party assets).

Where it looks broken

Comparing the boot path and the switch path on the wire:

• Boot: one session/follow stream, no cancellation, snapshot served once → renders fine.
• Switch: a new session/follow (assistantStream: true, maxMessages: 500, turnWindow: {minMessages:50, minTurns:2}) is opened, the old stream is cancelled, and the host then replays the entire assistant stream — for a large session that is ~1,700–3,570 assistant-stream items plus a 2–3 MB snapshot.

After this combination the transcript ends up with zero nodes and stays that way. So the suspect area is the client's session-switch handling: opening the new follow stream, cancelling the previous one, and applying the snapshot + the large assistant-stream replay.

Impact

Any user who switches sessions in a workspace with large sessions loses the ability to read any conversation in the app until they restart it; the only workarounds are the 轨迹 (Trajectory) tab or exported/archived transcripts.

中文摘要

桌面端 0.2.0-rc.2：启动后第一个会话能正常显示，但只要切换一次会话，「对话」面板就永久空白（转录节点数为 0），且不会自愈、会连带之后打开的所有会话，只有重启应用才恢复；同一会话的「轨迹」始终正常。已排除会话数据（74/74 通过官方四道校验）、第三方插件、布局高度、宿主未发数据、JS 报错等因素。抓包对比显示：启动路径正常，切换路径会新开 session/follow、取消旧流并回放整段 assistant-stream（大会话约 1700–3570 帧），此后转录即一直为空。怀疑是客户端在会话切换时对「新开流 + 取消旧流 + 大体量流回放」的处理缺陷。

[TTflysky]

Update: it still reproduces after a clean reinstall of the same official build

To rule out a damaged local installation (this machine had an unexpected power loss earlier), I downloaded the official 0.2.0-rc.2 installer from the update feed and verified it byte-for-byte before installing over the existing installation:

• source: https://download.deepseek.com/dsh-desk/bin/win-x64/deepseek-harness-0.2.0-rc.2-win-x64.exe (as advertised by feeds/win-x64/nightly.yml)
• size: 289313640 bytes — matches the feed exactly
• SHA-512: raIlxMQd9ESXgktmViW7QwVLcjBR5JIsrNOu+SpelY8kskdSr2H51/f+ey1EqFI/eIIrKQCuRANMeb5SptRZcg== — matches the feed exactly

After repairing the installation with that verified package and restarting the app:

1. the Conversation pane renders the first session correctly;
2. after switching several sessions, it goes blank again (transcript node count returns to 0);
3. the blank state persists for subsequently opened sessions.

So the behaviour is not environment-specific damage — it is reproducible with a pristine install of the same build. Data is unaffected (all sessions still pass DSH's own load path), and the Trajectory tab keeps working throughout.

中文补充

为排除"本机安装文件损坏"（这台机器此前意外断电），我从官方更新源下载了原版 0.2.0-rc.2 安装包，逐字节校验通过（大小与 SHA-512 均与官方 feed 一致）后覆盖安装并重启。修复安装后仍然复现：首个会话正常，连续切换多个会话后「对话」面板再次空白且不自愈。故该现象与本机环境损坏无关，可用干净安装稳定复现。

[TTflysky]

Correction: this is very likely a data-corruption problem in specific session logs, not a client defect

After reproducing the issue in an isolated instance (a copy of the user data + the official @deepseek-ai/dsh@0.2.0-rc.2 package, driven over CDP), the picture changed:

Sessions that render fine: untouched, never-repaired sessions — including large ones (3000+ events) — switching between sessions repeatedly keeps rendering correctly.

Sessions that render empty: only sessions whose stored logs had previously been repaired/rewritten by an external script (each of them carries backup copies of the pre-repair file). In the desktop client those sessions show a silent empty pane; in the web client the same sessions surface an explicit error:

历史加载失败：stored session "<id>" is corrupt:
stored log is corrupt: Error: corrupt session log:
invalid committed event at line <N>: released v2 row

So the reader is rejecting specific rows in those logs (invalid committed event … released v2 row), and the desktop client merely renders that failure as an empty transcript. The sessions pass the v4 row-admission / relationship / adoptSessionEvent / Session.fromRestore validations, yet the strict reader still refuses them — which is why the problem initially looked like a rendering bug on the client side.

Also ruled out in this round:

• Not client-wide: the same build renders other sessions correctly, repeatedly, including after many switches.
• Not poisoning: after several switches, previously-working sessions still render.
• Not the session-switch path: a clean instance, a clean data copy, and the empty result tracks the session identity, not the switch.

I will follow up with the exact offending row(s) once identified. Please treat the earlier "client defect" framing as superseded — apologies for the premature conclusion.

中文更正

在隔离实例（用户数据的副本 + 官方 @deepseek-ai/dsh@0.2.0-rc.2 包）中复现后，结论需要更正：

• 未被改动过的会话（含 3000+ 事件的大会话）反复切换都能正常渲染；
• 只有先前被外部脚本"修复/重写"过的会话会空白 —— 桌面端表现为无声空白，web 端则直接给出错误：invalid committed event at line <N>: released v2 row。

也就是说：读取器拒绝了这些日志里的特定行（疑似残留旧版行），客户端只是把该失败渲染成了空面板。这些会话虽然能通过 v4 的行准入/关系/adoptSessionEvent/Session.fromRestore 校验，但严格的读取器仍然拒绝它们。

同时排除：客户端全局缺陷（同版本其它会话反复切换正常）、"被污染"（多次切换后原本正常的会话仍正常）、切换路径（干净实例+干净数据副本下，空白只跟会话身份相关）。

此前"客户端缺陷"的定性作废，抱歉造成误判。定位到具体行后我会补充。

[TTflysky]

Final conclusion: it was corrupted session data, not a client defect — please disregard this report

Root cause found and fixed. The client is fine.

What was wrong. In the affected sessions, a prior third-party "repair" script had rebuilt the logs from archived transcripts and, in doing so, omitted two event types that the client needs in order to render a turn:

1. turn/end.reason — every turn/end lacked it. An affected turn renders as nothing at all: no transcript nodes, no error banner, no "load earlier" — which is exactly the silent blank pane. (Verified by removing reason from a healthy session: it goes blank in precisely the same way.)
2. request/header + request/context — the per-request model/tool metadata. Without them the model is unresolvable (the composer shows Custom), modelSelection.lastUsed projects to null, and the session's timing stats are all zero.

Why it looked like a client bug. The sessions passed every row-level validator, the host served the events correctly (I captured the session/follow snapshot: 359 records including 80 assistant/message events), and nothing ever errored — so the symptom looked like a rendering failure. The missing pieces only surface as absent projections, not as validation failures.

The fix and its verification. Adding turn/end.reason = {kind:'completed'} to each turn/end and inserting a request/header + request/context before the first assistant message of each turn:

• 69 of 74 sessions in the affected installation were repaired this way;
• 4 of 5 spot-checked sessions went from 0 transcript nodes → 92 / 260 / … nodes with the full conversation text rendered;
• all four official validators still pass: assertV4RowAdmission 74/74, assertReleasedV4Relationships 74/74, adoptSessionEvent 73/74, Session.fromRestore 73/74 (the single remaining failure is an unrelated self-referential sourceEventSeqs in one session, still being cleaned up);
• switching between sessions in an isolated instance repeatedly keeps rendering correctly.

Apologies for the noise — this report should be closed. The only genuine client-side observation that still seems worth a look, if you are interested, is that a turn whose turn/end.reason is missing renders as a completely silent empty pane with no diagnostic, which makes data problems very hard to tell apart from client bugs. A one-line warning there would have saved a lot of time.

中文结论（请忽略本报告）

根因是会话数据损坏，与客户端无关。 先前某个第三方"修复"脚本从归档重建日志时，漏掉了客户端渲染所需的两种事件：

1. turn/end.reason —— 缺失时该回合完全不渲染（无节点、无报错、连"加载更早"都没有），正是这个"静默空白"；
2. request/header + request/context —— 缺失导致模型无法识别（输入框显示 Custom）、modelSelection.lastUsed 为 null、时延统计全为 0。

补齐这两类事件后：69/74 个会话修复；抽查 5 个中 4 个从 0 节点恢复到 92/260 个节点并正常显示全文；四道官方校验仍全部通过（行准入 74/74、关系 74/74、事件接纳 73/74、完整装载 73/74，仅剩 1 个无关的自引用问题在清理）。

本报告可关闭，抱歉造成打扰。 唯一建议：turn/end.reason 缺失时界面完全静默，建议加一行提示，便于区分"数据问题"与"客户端问题"。