【BUG】客户端事件订阅器因 null 属性读取而死亡，导致转录区永久空白

[fm9527-cn]

【BUG】客户端事件订阅器因 null 属性读取而死亡，导致转录区永久空白
环境
@deepseek-ai/dsh-desktop 0.2.0-rc.2
Electron 44.0.0
Windows / x64
症状
侧边栏会话列表还在，但对话内容区永久空白
输入框可以打字，发送后界面无任何显示
重启客户端能短暂恢复；只要切换一次会话，立刻再次空白
控制台错误数随操作累积增长（3 → 15 → 24 → 52 → 64）
关键特征：故障跟随「切换会话」这个动作，而不是绑定某个特定会话。 这一点排除了「某个会话数据损坏」，指向共享的渲染通道。

根因
崩溃发生在客户端事件订阅器内部。该订阅器一旦抛出异常就会死亡，导致转录区停止更新并永久空白。

由于订阅器是按面板独立创建的，所以表现为：

崩溃前已渲染的内容保留（重启/重组后短暂正常）
崩溃后该面板永久空白
切换会话会重建订阅器并重放事件，再次踩中同一缺陷
核心错误：

代码块

[session-controller] event feed subscriber failed:
TypeError: Cannot read properties of null (reading 'kind')
三处缺陷
缺陷 1 — 收件箱事件拼接链未做空值防护
文件：dsh-client-ui-chat/lib/client.js 函数：materializePending() / applySplice()

js

function materializePending(state) {
const splices = [];
let current = state;
while (current.kind === "splice") { // ← 读取 null 的属性
splices.push(current);
current = current.previous; // ← 链尾是 null
}
const pending = [...current.ids]; // ← 再次读取 null
// ...
}

function applySplice(previous, splice, seq) {
const priorPending = previous?.state.pending ?? EMPTY_PENDING;
// ↑ 只护住了 previous，
// 没有护住 previous.state
}
分析：

splice 链通过 .previous 向前遍历，链头是 null。循环条件在判断类型前没有检查 current 是否存在。
另一处，可选链 previous?.state.pending 只对 previous 生效；当 previous 是「存在但 state 为 undefined」的对象时，.state.pending 依然会抛错。
缺陷 2 — turn/end 事件的 reason 可能为 null
文件：dsh-client-ui-chat/lib/client.js 函数：failureFrom() 等多处（共 11 处 reason 读取）

js

function failureFrom(match) {
if (match.event.type !== "turn/end") return void 0;
const reason = match.event.data.reason;
const failure = reason.kind === "error" ? reason.error : /* ... */;
// ↑ reason 可能为 null
}
缺陷 3 — trajectory 包的同源缺陷
文件：dsh-client-ui-trajectory/lib/client.js 函数：trajectoryTurnEndDefinition.start()

js

start: (_context, match) => {
if (match.event.type !== "turn/end") throw new Error(/* ... */);
const reason = match.event.data.reason;
const failure = reason.kind === "error" ? displayFailure(reason.error) : void 0;
// ↑ 同样未检查 null
// ...
}
注意： 报错栈显示 client.js:998，但该行号实际属于 trajectory 包——chat 包当时恰好也有相近行号，极易误判。多个 bundle 的文件名都是 client.js，行号不能作为唯一定位依据，需结合「该行附近是否有相关函数定义」交叉验证。

触发数据（来自真实会话日志）
全部会话共 13,441 条事件，其中 turn/end 的 reason 为 null 的有 7 条，分布在 3 个不同会话：

json

{"type":"turn/end","seq":1827,"data":{"turn":N,"reason":null}}
{"type":"turn/end","seq":2011,"data":{"turn":N,"reason":null}}
{"type":"turn/end","seq":2166,"data":{"turn":N,"reason":null}}
{"type":"turn/end","seq":1363,"data":{"turn":N,"reason":null}}
{"type":"turn/end","seq":9670,"data":{"turn":N,"reason":null}}
{"type":"turn/end","seq":9743,"data":{"turn":N,"reason":null}}
另有一条 agent/inbox/spliced 事件满足 removedCount > 0 且无 outcome 字段：

json

{"type":"agent/inbox/spliced","seq":5,"data":{"target":"next-turn","start":0,"removedCount":1,"inserted":[]}}
建议修法（最小改动，不改变正常流程行为）
修复 1 — chat 包补全空值防护

js

// a) 遍历链时检查空值
while (current != null && current.kind === "splice") {

// b) 空链时返回空数组
if (current == null) return [];

// c) 补全整条可选链
const priorPending = previous?.state?.pending ?? EMPTY_PENDING;
修复 2 — chat 包 11 处 reason 读取加可选链

js

event.data.reason?.kind
修复 3 — 在唯一入口统一归一化（conversation 包）

比起在 9 个调用点分别加防护，在 ConversationNodeAssembler.dispatchInput() 入口处理一次更稳妥：

js

dispatchInput(input, accept) {
input = normalizeTurnEndReason(input); // ← 注意：必须替换 input 本身
const event = input.event;
// ...
}

function normalizeTurnEndReason(input) {
const event = input !== null && typeof input === "object" ? input.event : void 0;
if (event === null || typeof event !== "object") return input;
if (event.type !== "turn/end") return input;
const data = event.data;
if (data === null || typeof data !== "object") return input;
if (data.reason !== null && data.reason !== void 0) return input;
return { ...input, event: { ...event, data: { ...data, reason: { kind: "unknown" } } } };
}
⚠️ 这里的坑： 最初的实现写成 const event = normalizeTurnEndReason(input.event); ——只修复了局部变量，而下游 acceptMatch() 使用的是 input 本身，导致 start() 仍收到未修复的事件。 修补「统一入口」时必须确认下游真正使用的是哪个对象。

修复 4 — 两处 reason 赋值加默认值

js

const reason = match.event.data.reason ?? { kind: "unknown" };
补充说明
我确认过 Discussions 中已有的 321 个报告。 「Web UI 与前端」这一类里没有这一条：
#317 / #370 是长思考导致页面卡死（Maximum call stack size exceeded）
#682 / #1316 是工具调用循环拖垮浏览器
症状与根因均不同。本条的特殊之处是：症状为「静默空白」，不打开 DevTools 就找不到入口。
本地已按上述方案修补 app.asar（仅 3 个文件，0 新增 0 删除，全部 11,470 个内联文件保持一致），并通过 5 层验证：
结构完整性（逐文件 SHA256 比对）
行为测试（materializePending(null/undefined)、null 结尾的 splice 链等）
用 7 个真实记录的 null-reason 事件直接调用修复后的 start() 闭包 → 0 抛错
14,341 条真实事件全量回放 → 0 异常
全量客户端 bundle 编译测试
一个建议（比补丁本身更重要）
即使不采纳上述补丁，也希望考虑给事件订阅器加一层保护。

目前任何一个订阅器抛异常，都会造成「整个面板永久空白、且界面不给任何提示」——这个失败模式太隐蔽了。 一个 null 字段就能让用户以为「对话全部丢失」。

至少应该：

订阅器外层加 try/catch，捕获后降级并给出可见提示，而不是静默死亡
或在开发模式下把订阅器异常打到界面上
本报告由用户与其 DSH 内的 AI 助手协作完成。修复补丁与全部验证脚本保留在本地，可按需提供。

[argszero]

All three findings reproduce in the TypeScript sources behind those bundles, and the second one has a cause that is worth naming precisely — because the null you are crashing on is not "a turn that ended without a reason". It is the signature of a finalization that failed.

Source locations. Your client.js paths are the bundles; these are the files they are built from, and the line numbers below are master:

• Defect 1 — packages/client/ui-chat/src/client/conversation-nodes/inbox.ts:46-58 (materializePending). The walk is exactly as you read it: let current = state then while (current.kind === 'splice') { … current = current.previous }. The type it walks is PendingSplice.previous: PendingState (:23-29) — declared non-nullable — so the loop encodes "the chain terminates in a snapshot" as an assumption, and nothing checks the runtime link. The trajectory twin is packages/client/ui-trajectory/src/client/trajectory-message-definitions.ts:51 and its applySplice at :84-92.
• Defect 2 — packages/client/ui-chat/src/client/apply.ts:107, conversation-nodes/turn-error.ts:37, conversation-nodes/turn-max-tokens.ts:42 and :51, conversation-nodes/turn-tail.ts:82, packages/client/ui-trajectory/src/client/trajectory-assistant-definition.ts:440, packages/client/ui-workflow-run/src/client/workflow-definition.ts:91.
• Defect 3 — the trajectory reader is trajectory-assistant-definition.ts:440, as you suspected.

Where the null comes from. packages/core/agent-loop/src/agent.ts:

let turnEnds: TurnEndReason | null = null        // :312
…
this.session.append('turn/end', { turn, reason: turnEnds! })   // :387

The append sits in a finally, and the ! is silenced by an oxlint-disable typescript/no-non-null-assertion whose comment reads "every exit assigns a turn ending" — an invariant asserted in a comment, not a check. The way it breaks is one function above: abortedCancelCause (:80-95) ends in assertNever(cause) (:92-93) for any cancel cause outside AgentCancelCause (user | parent | hook | disposed). A cancel carrying anything else makes the abort-handling path throw; that throw leaves the catch, the finally still runs and still appends, and turnEnds is still the initial null. The event is written, the log accepts it, and the client reads reason.kind.

So the two facts that make this a visible defect rather than a contained one:

1. The durable log can hold a value the type denies. packages/core/session/src/types.ts:298 declares 'turn/end': { turn: number; reason: TurnEndReason }, and nothing at the append boundary validates it — the field is written as-is.
2. The reader side is inconsistent about it. At least one reader already knows: packages/client/ui-tool/src/client/tool/models/auto-review-denial.ts:16 opens with if (reason === null) return null. Six other readers assume the non-nullable declaration. Your Cannot read properties of null (reading 'kind') is what the second group does when the first group's assumption is wrong.

This writer-side defect has four earlier reports. Discussions #8832, #9156, #9646 and #9699 all end at this same line, and their symptom is a blank session list rather than a blank transcript. Yours is the client-side reader of the same null — which is useful evidence for the report: the same missing-reason write reaches at least two independent consumers, and neither is written to survive it.

What already exists in this direction. We published @argszero/dsh-cancel-cause-guard (npm, v0.2.0) for the writer half: it shadows Session.append and rewrites an unresolvable turn/end.reason into the ending the loop meant to write, so the session list keeps its rows and a client like yours never receives the null. Be clear about what that is: a band-aid over a core writer. The core fix is still the right one — assign a fallback ending in the loop before the finally can append, and/or reject a missing reason loudly at the append boundary instead of persisting null into a log that the type says cannot contain it. A reader-side guard alone would hide the failure while leaving the log wrong.

On the three fixes themselves:

• The chain walk should be structural rather than a type assumption: treat an absent link as the snapshot root. Today const priorPending = previous?.state.pending ?? EMPTY_PENDING (inbox.ts:84) guards previous === undefined — a case the ConversationPreviousContext | undefined type does allow but which the code otherwise treats as impossible — while the chain link that the type also declares non-nullable is left unguarded. Whatever the intended root is, one form of it should be a value, not a branch.
• reason.kind reads should go through one narrow accessor (something like turnEndReason(event): TurnEndReason | undefined, returning undefined for null) so the six readers cannot each decide independently whether the log can violate its own type. auto-review-denial.ts:16 is the shape to standardise on.
• Your bundle-identification note is worth keeping in the report: several bundles are named client.js, so a line number cannot identify one, and only "is the relevant function defined near this line" can. That is exactly how three separate defects were collapsed into one stack frame here.

If you can share what was cancelling in the three sessions that carry the seven null rows — a Stop, a parent cancel, or a plugin's own cancellation — that would name which cause escapes the union and confirm the producer above from the other end.

[fm9527-cn]

Thanks — this reply is far more useful than the report it answers. You took three bundle-level findings and named the writer-side producer, which we could not reach from the client side. Two follow-ups, one of which may not match your hypothesis.

What was cancelling? (your last question)
We pulled it from the session logs. Every reason: null is preceded by the same shape, 24 times out of 24, across 5 sessions (16,506 events total):

代码块

assistant/message {turn=N step=M} ← reasoning only: no text, no tool/call
step/end {turn=N step=M}
turn/end {reason=null}
Distribution: 14 / 0 / 0 / 4 / 6 per session. Turns seen: 61 / 63 / 65 / 67 / 79 / 82 / 83 / 88 / 96 / 99 / 108 …

Two things to note:

Those turns contain no tool/call at all. Each one is a step that produced reasoning and then nothing.
We found no cancel-typed event anywhere in these five logs. (Method note, since it bounds the claim: we scanned every event for the substrings cancel/abort; every hit was an ordinary event whose content happened to contain the word — request/header with cause="resume"|"change"|"series"|"initial", tool/result, compaction/summary. That is a coarse screen, not a type-level query, so treat it as "no obvious cancel events" rather than proof of absence.)
So we cannot confirm the abortedCancelCause → assertNever path from this end. Either the cancel is invisible to the durable log, or the missing assignment happens on a different exit — specifically, the branch the loop takes when a step produces no text and no tool-call. Given the client-side symptom is "reasoning ran, then the turn just stopped", the second reading seems closer.

If cancels are not logged, that would itself be worth knowing — it makes this class of bug unobservable from the outside.

A trap in reading these logs (may be useful to you)
session.v4.jsonl.zstd is concatenated Zstd frames — one per line, not a single frame. node:zlib's one-shot decompressors (zstdDecompressSync) and even createZstdDecompress() stop after the first frame, so a 2 MB log yields exactly one event and looks like an empty session.

You have to walk the buffer by the Zstd magic (28 B5 2F FD) and inflate frame by frame:

js

const MAGIC = Buffer.from([0x28, 0xb5, 0x2f, 0xfd]);
const offs = [];
let i = 0;
while ((i = buf.indexOf(MAGIC, i)) !== -1) { offs.push(i); i += 4; }
offs.push(buf.length);

const events = [];
for (let k = 0; k + 1 < offs.length; k++) {
try {
for (const line of zstdDecompressSync(buf.subarray(offs[k], offs[k + 1])).toString('utf8').split('\n')) {
if (line.trim()) events.push(JSON.parse(line));
}
} catch { /* magic byte pair inside compressed data — skip */ }
}
Frame counts for reference: 1316 / 21 / 11 / 2098 / 5346. Attached below as scan-null-reason.mjs — it prints each null-reason turn/end with its preceding N events.

Note if you run it and paste output: the script echoes the session directory name (=== session-). Strip those before sharing.

One question about your plugin
We patched the reader side (rebuilt app.asar, three files, 0 added / 0 removed of 11,470 entries) before this discussion existed. That fix is lost on every client upgrade.

@argszero/dsh-cancel-cause-guard addresses the writer, which is the right layer. If we install it, is the reader-side patch still needed — i.e. does the guard reliably prevent null from ever reaching the durable log, or should both stay in place? We would rather delete our app.asar patch than keep a local fork of the client that silently reverts.

Also: you wrote the core fix correctly — a reader-side guard alone hides the failure while leaving the log wrong. Agreed, and it is why we reported this rather than just shipping the patch.

scan-null-reason.mjs
js

// Scan DSH session logs for turn/end events whose data.reason is null,
// then dump the events immediately before each — to identify what cancelled.
//
// DSH writes session.v4.jsonl.zstd as CONCATENATED Zstd frames (one per line),
// so node:zlib's single-shot decompressors only give you the first event.
// This walks the buffer by Zstd magic number and inflates frame by frame.
//
// Usage: node scan-null-reason.mjs [sessionsDir] [contextLines]
import { readdirSync, readFileSync, existsSync } from 'node:fs';
import { join } from 'node:path';
import { zstdDecompressSync } from 'node:zlib';

const root = process.argv[2] ?? join(process.env.USERPROFILE ?? '', '.dsh', 'sessions');
const CTX = Number(process.argv[3] ?? 8);
const MAGIC = Buffer.from([0x28, 0xb5, 0x2f, 0xfd]);

function findLogs(dir) {
const out = [];
for (const ws of readdirSync(dir, { withFileTypes: true })) {
if (!ws.isDirectory()) continue;
const wsPath = join(dir, ws.name);
for (const s of readdirSync(wsPath, { withFileTypes: true })) {
if (!s.isDirectory()) continue;
const f = join(wsPath, s.name, 'session.v4.jsonl.zstd');
if (existsSync(f)) out.push({ session: s.name, file: f });
}
}
return out;
}

function readFrames(file) {
const buf = readFileSync(file);
const offs = [];
let i = 0;
while ((i = buf.indexOf(MAGIC, i)) !== -1) { offs.push(i); i += 4; }
offs.push(buf.length);

const events = [];
let bad = 0;
for (let k = 0; k + 1 < offs.length; k++) {
    let text;
    try { text = zstdDecompressSync(buf.subarray(offs[k], offs[k + 1])).toString('utf8'); }
    catch { bad++; continue; }
    for (const line of text.split('\n')) {
        const t = line.trim();
        if (!t) continue;
        try { events.push(JSON.parse(t)); } catch { /* skip */ }
    }
}
return { events, frames: offs.length - 1, bad };

}

function brief(ev) {
const bits = [];
const d = ev.data ?? {};
if (typeof ev.seq === 'number') bits.push(seq=${ev.seq});
for (const k of ['turn', 'step', 'reason', 'cause', 'kind', 'status', 'target', 'role']) {
if (d[k] === undefined) continue;
let v = d[k];
if (typeof v === 'object' && v !== null) v = JSON.stringify(v);
bits.push(${k}=${v});
}
return ${ev.type ?? '?'} {${bits.join(' ')}};
}

const logs = findLogs(root);
console.log(logs: ${logs.length}\n);

let total = 0;
const causeTally = new Map();

for (const { session, file } of logs) {
const { events, frames, bad } = readFrames(file);
const hits = [];
for (let i = 0; i < events.length; i++) {
const e = events[i];
if (e.type === 'turn/end' && e.data && e.data.reason === null) hits.push(i);
}
console.log(=== ${session});
console.log( frames=${frames} (bad=${bad}) events=${events.length} null-reason turn/end=${hits.length});
total += hits.length;

for (const i of hits) {
    console.log(`\n  --- event #${i + 1}  turn=${events[i].data?.turn} ---`);
    for (let j = Math.max(0, i - CTX); j < i; j++) {
        console.log(`    [${j + 1}] ${brief(events[j])}`);
    }
    console.log(`    [${i + 1}] ${brief(events[i])}   <<< NULL REASON`);
}
console.log('');

for (const e of events) {
    const s = JSON.stringify(e);
    if (/cancel|abort/i.test(s)) {
        const key = `${e.type} | cause=${JSON.stringify(e.data?.cause ?? e.data?.reason ?? null)}`;
        causeTally.set(key, (causeTally.get(key) ?? 0) + 1);
    }
}

}

console.log(\nTOTAL null-reason turn/end: ${total});
console.log('\n=== cancel/abort-shaped events (top 30) ===');
[...causeTally.entries()].sort((a, b) => b[1] - a[1]).slice(0, 30)
.forEach(([k, v]) => console.log( ${String(v).padStart(6)} ${k}));