[Bug] 尾部为 pending 工具调用的会话被 crash-recovery 合成坏 tool/result ⇒ 会话永久不可读 / 不可 resume

[zhaocjiang]

现象

某会话日志（session.v4.jsonl.zstd）的尾部是一个未完成的工具调用：

• assistant/message（seq 21293）含 tool-call 块 { id: "", name: "", arguments: "{\"bash\":\"\",\"command\":\"…\",…}" }
• 配对的 tool/call 事件（seq 21294）为 { callId: "", name: "", turn: 64, step: 32 }，且悬空（会话在此处被掐断）

之后该会话的任何读取路径都失败：

1. @ 引用 / 读取：failed to read referenced session: session event at seq 21295 message must have tool source
2. 重开会话发「继续」（resume）：本轮运行失败 format v4 tool/result at seq 21295 requires toolCallId matching its tool source

即：尾部是 pending 工具调用的会话，永久不可读、不可恢复、不可被 @ 引用。

环境

• 宿主 0.2.1-rc.2（linux / systemd）
• 模型 agnes-3.0-flash，API openai-completions（流式）
• 该模型流的 tool-call-delta 块 id 从头就是 ""（provider 未提供工具调用 id）

根因（两层）

1. 写侧：空 tool-call id 被原样持久化

provider 流未携带 tool-call id 时，持久化没有「合成确定性非空 id」的兜底：tool-call 块 id、tool/call 事件 callId/name 全空入库。

2. 读侧：crash-recovery 合成出违反自身不变量的 tool/result

@deepseek-ai/dsh-session 的 ToolCallRecovery.results()（lib/index.js 约 L857）对 pendingCalls 里每个键无条件合成：

for (const [callId, { turn, step, callSeq }] of this.pendingCalls) {
  const message = deepFreeze({
    role: "tool",
    toolCallId: callId,
    source: { kind: "tool", callId },   // callId === "" ⇒ 违反「tool source 必须非空」
    ...

pending 键来自 assistant 消息的 block.id（本例为空）⇒ 合成事件过不了 assertMessageEventShape ⇒ 报错 ①。

把日志里块 id 手工补成非空后，又撞上 resume 活体路径的第二道校验：其合成的 tool/result 的 message.toolCallId 与 message.source.callId 取自不同来源、彼此不一致 ⇒ format-v4 校验器拒收（报错 ②）。

影响

任何在「空 id 工具调用」处被中断的会话都永久卡死；当前唯一绕行 = 手工把日志截到最后一条干净 step/end 边界（本会话即如此处理），代价是丢掉进行中的 step 内容。

建议修复

1. 写侧：provider 响应缺 tool-call id 时，合成确定性非空 id（块与 tool/call 事件带同一值；name 不允许空）。
2. 读侧 results()：跳过空键 pending，或合成自洽的非空 id —— 在所有合成 tool/result 的位置（含 live resume 合成器）保证 message.toolCallId === message.source.callId。
3. 回归测试：以「pending 空 id 工具调用」结尾的日志 ⇒ load + 合成闭合事件全部过校验；负向对照：撤守卫即红。

证据

• 修前探针（宿主同款 adoptSessionEvent + interruptedTurnClosers 跑真实日志）：逐字复现报错 ①；
• 块 id 手工补非空后：逐字复现报错 ②；
• 截到最后一条 step/end 后：recovery 仅合成 turn/end，全链校验通过（退出码 0），会话可读。

---

补充复现（第二个宿主构建：0.2.1-rc.5）

在第二台实例（宿主 0.2.1-rc.5）上复现了完全相同的报错：

本轮运行失败 format v4 tool/result at seq 5312 requires toolCallId matching its tool source

盘上取证（session.v4.jsonl.zstd）

项	值	含义
日志 maxSeq	5311	报错里的 5312 在盘上不存在 —— 由读侧 crash-recovery 合成
末事件 seq 5311	tool/call，callId=""、name=""（arguments 有实际内容）	写侧缺陷：宿主把一条没有 id 的 tool-call 记进了日志
相邻 seq 5306	tool/call（带正常非空 callId）	空 id 不是普遍现象，是偶发写侧缺陷
报错 tool/result@5312	盘上 5311 之后无 5312	合成的 result 其 toolCallId 对不上源 5311 的空 id ⇒ 校验失败

因果链与主诉逐字吻合：写侧记了空 id 的 tool/call（5311）→ 会话停在此处未收尾 → 读侧 crash-recovery 合成一条 tool/result（5312）收尾，id 对不上 ⇒ requires toolCallId matching its tool source。

汇总（跨宿主构建）

宿主构建	触发空 id 的 tool/call	报错 seq
0.2.1-rc.2	尾部悬空 pending tool-call	21295（合成）
0.2.1-rc.5	seq 5311 空 id tool/call	5312（合成）

两份不同宿主构建（rc.2 / rc.5）都复现，缺陷位于宿主核心（写侧空 id + 读侧合成器不匹配）。