[Bug] 0.2.2-rc.1：空 tool-call id 落盘 + 恢复期在磁盘上不存在的 seq 合成自相矛盾 TOOL_NOT_STARTED repair ⇒ 会话永久不可读（帧级证据 + 已验证修复）

[czyt1988]

环境

• DSH Desktop 0.2.2-rc.1（@deepseek-ai/dsh-desktop / @deepseek-ai/dsh-desktop-runtime），Windows 11 x64
• 内置 Node.js v24.21.0
• 模型侧 provider bt，model qwen3.8-max，API openai-completions
• 会话：session-a5389df2-c08c-4bbe-8541-01f0c613d689，cwd = F:\src\interactive-class，单 turn 内连续 73 个 step

现象

该会话此后每次打开都会失败，报：

format v4 tool/result at seq 445 requires toolCallId matching its tool source

会话永久不可读、不可 resume，且 UI 没有修复或重扫入口。

根因（两层缺陷叠加）

1) 模型返回了完全为空的 tool call，DSH 写侧未拦截，直接落盘

seq 443 的 assistant/message 是模型本次输出，其 stream 里工具调用块为空：

{ "type": "chunk", "chunk": { "type": "tool-call-delta", "index": 1, "id": "", "argumentsDelta": "" } }
{ "type": "chunk", "chunk": { "type": "block-end", "index": 1,
  "block": { "type": "tool-call", "id": "", "name": "", "arguments": "{}" } } }

同一条消息的 finish.reason 仍是 { "kind": "tool-calls" }，replayState.response.stopReason 为 toolUse，responseId: chatcmpl-96fcbe90-8f13-9731-899a-f36b75a373dc。

DSH 随后把它原样写成 seq 444：

{ "type": "tool/call", "seq": 444,
  "data": { "turn": 1, "step": 73, "callId": "", "name": "", "arguments": "{}" } }

注意 callId 与 name 都是空字符串。校验器本身是知道这个不变量的——assertReleasedPayloadSemantics 对 tool/call 明确要求 nonEmptyString(data["callId"])、nonEmptyString(data["name"])，但实时追加路径没有执行该校验，于是坏行进了日志。这与 #7944 "V4 写侧 admission 不校验 tool-call 的 id/name" 的判断一致。

2) 崩溃恢复为这个悬空调用合成 repair，而 repair 自身违反校验器 ⇒ 自锁

日志尾部只有"已通告、未启动"的 tool call，没有对应的 tool/result。恢复流程会为它合成一条 TOOL_NOT_STARTED 修复结果（interrupted-tool-result-<callId>-<seq>），但从空的 callId 派生，于是 message.toolCallId === ""，撞上 assertV4ToolResultMessage 的

if (typeof toolCallId !== "string" || toolCallId.length === 0 || sourceCallId !== toolCallId)
  throw new SessionFormatError(`${subject} requires toolCallId matching its tool source`);

subject 就是报错里的 format v4 tool/result at seq 445。

关键证据：磁盘文件中根本不存在 seq 445。文件最后一个事件是 seq 444，445 是恢复期在内存中合成出来的——也就是说恢复逻辑每次都在同一处生成一个自己拒绝接受的行，形成确定性死循环（与 #9731 "崩溃恢复每次都在同一 seq 自锁" 同因）。

帧级证据

文件 session.v4.jsonl.zstd = 473757 字节，zstd 多帧容器，共 252 帧：

帧	字节区间	内容
248	470401–472323	assistant/message@438, tool/call@439
249	472323–472856	tool/result@440, step/end@441
250	472856–472945	step/start@442
251	472945–473757	assistant/message@443, tool/call@444（含空 id/name）

损坏内容完整落在最后一帧内，与前 251 帧边界清晰。截断后事件数 443（header + seq 0–442），seq 连续无缺口。

本地修复（已验证）

在帧边界 472945 处截断到 step/start@442（保留部分是原文件的精确字节前缀），再用 DSH 自带的校验 worker 复核：

• 修复后：verifyJsonlCurrentGeneration → decodeCurrentGeneration → validateStoredEvents → Session.fromRestore → 嵌入流全量重放，结果 ok: true，digest 299af7b6cd092c2037202c7320be527c6218776ed1af46cd9e1f5b67f8a0b464
• 原始文件：同一校验路径报 SessionFormatError: tool call id requires a nonempty string（Relationships.tool）

数据损失仅为那条空工具调用本身（一句 reasoning，无回答文本）。这说明日志主体是完好的，坏的只是尾部一个不可执行的调用——完全可以通过一个宽容的恢复策略救回来，不需要用户手工剪帧。

建议修复方向

1. 写侧 admission（根因）：tool/call 落盘前校验 callId/name 非空；更靠上游一点，在 provider 适配层（llm-pi-ai / openai-completions 适配器）把"stopReason = toolUse 但 tool call 缺 id/name"识别为协议错误，丢弃该调用并把本轮视为异常结束（或补一个确定性的合成 id），不要产生不可执行的悬空调用。当前行为是把上游协议异常写成了永久损坏。
2. 恢复侧收敛：对历史里已存在的空 callId 行做宽容归一化（例如派生确定性 id empty-tool-call-<seq>，并让 repair 复用同一 id），而不是合成一条被自己校验器拒绝的 repair。校验器与恢复器必须对"从不变量违例中恢复"达成一致，否则任何一条坏行都会变成不可恢复点。
3. 提供 re-scan / repair 入口：日志损坏后用户目前完全无从下手（同 [桌面端] 会话日志损坏后不可恢复、也无法再出现在列表中（seq gap / does not match an open turn and step，缺修复与重扫入口） #11230 的诉求）。至少应给出"截断到最后一个合法边界"的显式修复操作，并保留原文件备份。
4. 测试用例：建议补一条回归测试——constructed artifact 中 step/start 后跟 assistant/message（tool-call id="") + tool/call（callId=""）且无 result，断言 (a) 写侧拒绝，(b) 若已存在则恢复可读。

已知重复

同一缺陷在 Discussions 中已被多次报告，均未见修复，版本跨度 0.1.7-rc.2 → 0.2.2-rc.1：

• [Bug] V4 写侧 admission 不校验 tool-call 的 id/name：会话或永久打不开、或每次请求 400（0.1.7-rc.2 桌面端，含实测会话与帧级证据） #7944 V4 写侧 admission 不校验 tool-call 的 id/name
• Bug: 模型输出空 id 的 tool-call 会导致会话永久卡死（format v4 tool/result ... requires toolCallId matching its tool source） #8653 模型输出空 id 的 tool-call 会导致会话永久卡死
• [Bug] 空 id/name 伪 tool-call 落盘后 tool/result 校验永久失败，会话从该 seq 起卡死（0.1.7-rc.2 → 0.2.1-alpha.1 均未修，附本地已验证补丁） #9215 空 id/name 伪 tool-call 落盘后 tool/result 校验永久失败（附本地补丁）
• Session 日志可被空 toolCallId 永久锁死：崩溃恢复每次都在同一 seq 自锁 #9731 Session 日志可被空 toolCallId 永久锁死：崩溃恢复在同一 seq 自锁
• [Bug] empty tool-call id/name from Anthropic Messages gateway → "format v4 tool/result requires toolCallId matching its tool source" crash (fix provided) #10732 Anthropic Messages gateway 空 tool-call id/name（fix provided）
• [Bug] llm-pi-ai forwards empty tool id/name, crashing the session write (assertV4ToolResultMessage) #11151 llm-pi-ai forwards empty tool id/name
• [Bug] 尾部为 pending 工具调用的会话被 crash-recovery 合成坏 tool/result ⇒ 会话永久不可读 / 不可 resume #12179 尾部为 pending 工具调用的会话被 crash-recovery 合成坏 tool/result

本贴补充的是 0.2.2-rc.1 上的新证据：空 id 不仅来自 Anthropic/Messages 网关，也能来自 openai-completions 侧的 bt provider；并且给出了"恢复期在文件中不存在的 seq 上合成自相矛盾 repair"的帧级证明与已验证的本地修复路径。建议把这一族问题合并处理，因为它会稳定地把任何一次上游协议异常升级为不可恢复的会话。