[BUG] 会话日志中一条 tool/result 引用了不存在的 call id，导致该会话所有请求被供应商 400 拒绝，永久不可用

[Semidia]

[BUG] 会话日志中一条 tool/result 引用了不存在的 call id，导致该会话所有后续请求被供应商以 400 拒绝，永久不可用、无自愈路径

English Summary (TL;DR)

A single corrupted tool/result event in a session log cites a call id that never existed in any assistant message. From then on, every LLM request in that session is rejected by the provider with 400 INVALID_REQUEST — "An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id', The following tool_call_ids did not have response messages: …" — and the session is permanently deadlocked. The harness has no validation of tool-call ↔ tool-result pairing when deriving/serializing the transcript, and the crash-repair path (interruptedTurnClosers) only covers open tail turns at load, so a mismatched call id inside a closed turn is never detected or repaired. Surface replacement for tool/result is additionally restricted to changing only content (assertToolResultRewrite: "may change only content"), so even manual recovery through supported APIs is impossible; we had to patch the JSONL file directly.

Environment: @deepseek-ai/dsh 0.1.0-rc.6, web profile, Windows, JSONL+zstd session persistence.

---

1. 现象

• GUI 显示：本轮运行失败 + An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id', The following tool_call_ids did not have response messages: call_efaab339117449e8b1e79c44（HTTP 400, INVALID_REQUEST）。
• 同一会话连续重试 3 次（第 12、13、14 轮），每次都在第一步请求即失败，会话完全无法继续。

2. 根因（有完整证据链）

会话 session-28edf83f-…，第 7 轮 step 1：

seq	事件	内容
10438	assistant/message	工具调用：todo_write(call_f8b23eafdd7a4237b572fcec) + pwsh(call_97d60fa2b6314cd383925ab6)（流式 chunk 10293–10435 中的 id 与此一致）
10439 / 10441	tool/call / tool/result	todo_write，引用 f8b23eaf… ✓
10442	tool/call	pwsh，引用 97d60fa2… ✓
10443	tool/result	引用 call_efaab339117449e8b1e79c44 —— 该 id 在整份日志中从未出现在任何 assistant 消息或 tool/call 里；且 step=2（调用在 step 1）、无 sourceEventSeqs、isError=false

用与 dsh-llm-deepseek 完全相同的 wire 序列化逻辑复现，发给供应商的历史为：

assistant tool_calls = [call_f8b23eaf…, call_97d60fa2…]
tool messages       = [call_f8b23eaf…, call_efaab339…]   ← 97d60fa2 无应答 → 供应商 400

该坏事件不符合 Harness 任何正常写入路径的特征：

• appendToolResult（dsh-agent-loop）总是带 sourceEventSeqs 且使用 assistant block 的 id；
• 崩溃修复 interruptedTurnClosers 合成的结果总是 isError=true 且带 error code；
• tool-result pruner 只做 surfaceOp: replace 且保留 callId。

→ 结论：该事件来自写入竞争（torn/interleaved write），而非正常逻辑。

3. 触发场景（重要）

第 7 轮代理执行的 pwsh 命令本身在重命名 sessions 目录：

Rename-Item C:\Users\Administrator\.dsh\sessions → sessions.old
New-Item -ItemType Junction C:\Users\Administrator\.dsh\sessions → D:\...\dsh-sessions

即：Harness 正在向会话日志追加写入时，其持久化目录被改名 + 换成 junction（Windows 下 O_APPEND 句柄与目录 rename/junction 并发）。同一会话更早还有另一处损坏（seq 488 agent/inbox/spliced 的 removedCount 异常，只能手工修补），进一步佐证写入流被破坏。

4. Harness 缺口（希望修复的点）

1. 无配对校验：Session.deriveMessages() / 各 adapter 的 wire 序列化不做 "assistant tool-call ↔ tool 消息" 配对校验。日志一旦出现错配记录，wire 历史必然非法，供应商 400，Harness 无检测、无恢复。
2. 崩溃修复覆盖不足：interruptedTurnClosers 只处理加载时「尾轮未闭合」的情况；「已闭合轮次内的错配 call id」完全覆盖不到（本例轮次已正常闭合，只是轮内结果引用错误）。
3. 修复途径被锁死：tool/result 的 surface replacement 被 assertToolResultRewrite 限制为只能改 content（message.source.callId 在比对范围内），因此即使想通过受支持的 API 修正 call id 也不被允许，只能手工改文件。
4. UX 无提示：GUI 只透传供应商原文错误，用户无法判断是"会话日志已损坏"，只能反复重试。
5. 持久化目录无保护：sessions 目录被 rename/junction 时没有保护或检测；加载时只有帧结构校验，没有事件级语义校验（seq 连续、call id 配对）。

5. 建议修复方向

1. 在 deriveMessages 或序列化前做配对校验：对每条 assistant tool-call，确认其后存在同 id 的 tool 消息；错配时自动修复（如把结果 id 修正为最近的未应答调用）、丢弃孤儿记录，或至少记录 session/corruption 事件并在 UI 提示。
2. 扩展 interruptedTurnClosers（或新增 transcript-repair pass）覆盖已闭合轮次：扫描全日志，修正/清除引用了未知 call id 的 tool/result。
3. 为修复工具结果提供受支持途径（允许通过 surface replacement 修正 call id，或提供专门的 repair API）。
4. GUI 遇到此类"历史无效"错误时提示"会话日志可能损坏，可新建会话/联系支持"，并给出会话 ID。
5. Windows 下对持久化目录改名/move 增加防护，或写入时校验路径身份；并对日志做事件级校验。

6. 证据材料（可按需提供）

• 修复后的会话日志：C:\Users\Administrator\.dsh\sessions\…\session-28edf83f-….jsonl.zstd（修复前备份在 D:\ds harness默认工作区\session-28edf83f.jsonl.zstd.bak）
• 修复脚本：D:\ds harness默认工作区\repair-broken-session.mjs（逐帧重编码，仅改 seq 10443 的 callId + step）
• wire 复现脚本：D:\ds harness默认工作区\wire-repro.mjs
• 会话扫描脚本：D:\ds harness默认工作区\scan-all-sessions.mjs（可复现"全日志仅此一处错配"）

修复方式说明：由于 surface replacement 不允许改 callId，只能直接重写 zstd-jsonl 中 seq 10443 这一条记录（callId/toolCallId 改为 call_97d60fa2…，step 2→1），其余 1693 个 zstd 帧字节原样保留；修复后全日志 0 悬挂调用、0 孤儿结果，wire 校验通过。

[argszero]

对着 master（47f943859b）把五条主张逐一核实——全部成立，而且这条是序列化中毒家族的第四条路径、也是 #1337 的镜像。逐条确认 + 一个你还没点到的更广缺口 + 修复排序：

源码确认（5 条全中）

1. appendToolResult 永远带 sourceEventSeqs 且用 assistant block 的 id：core/agent-loop/src/tool-calls.ts:268-290——callId: block.id + sourceEventSeqs: [callSeq]。✓
2. interruptedTurnClosers 合成的结果永远 isError=true + error code：core/session/src/repair.ts（TOOL_OUTCOME_UNKNOWN/TOOL_NOT_STARTED）。✓
3. assertToolResultRewrite 只允许改 content：core/session/src/surface.ts:287-325——message 整体（含 source.callId）进深比较，只把 content 挖空，改 callId 必然 throw。✓ 所以"受支持 API 无法修"属实。
4. wire 序列化无配对校验：llm-deepseek/src/serialize.ts:105-140——serializeMessages 把 tool-result block 原样映射成 {role:'tool', tool_call_id: result.toolCallId}（:134），serializeAssistant 把 tool_calls 原样重放；没有任何"assistant 的 call id ⊆ 后续 tool 消息的 call id"检查。✓
5. 坏事件不符合任何正常写路径——这是最重要的：它没有 sourceEventSeqs，而 tool/result 是 surface 类型，正常路径 appendToolResult 必传 opts；空 opts 的事件只能来自非正常写入。✓

你没点到的更广缺口：surface fold 本身也不做配对校验

assertProvenance（surface.ts:211+）只校验 sourceEventSeqs 的形状（安全整数、引用更早事件、无重复）——从不检查被引用的 seq 是否真的是同 callId 的 tool/call；而完全没有 sourceEventSeqs 的事件直接通过（raw === undefined 时 sources 为空、无 missing）。也就是说配对校验缺失不仅在 wire 层（你的主张 1），在日志自身的 surface 一致性层也没有——这解释了为什么这条坏事件能一路从 append 进日志、过 surface fold、到序列化才被供应商 400 拦住。

家族定位：第四条路径 + 首个文件系统层机制

• 镜像关系：Community plugins resolving a second @deepseek-ai/dsh-tools copy crash the tool scheduler with Cannot read properties of undefined (reading 'prepare') #1337 = 有 tool_call 无 result（scheduler 崩溃后悬空）；[BUG] 会话日志中一条 tool/result 引用了不存在的 call id，导致该会话所有请求被供应商 400 拒绝，永久不可用 #1593 = 有 result 无 tool_call（孤儿 result）。两条各缺一半，供应商的 "tool_call_ids did not have response messages" 与 "did not have matching tool_calls" 是同一校验的两面。合并进统一工作流（我在 bug 任何会话只要遇到截断在 emoji 中间的工具结果，就会永久 400 无法继续 #1449/Bug + tested fix: truncated tool-call arguments permanently poison a session (llm-deepseek serializer) #1519 帖过）：bug 任何会话只要遇到截断在 emoji 中间的工具结果，就会永久 400 无法继续 #1449 孤立代理对、Bug + tested fix: truncated tool-call arguments permanently poison a session (llm-deepseek serializer) #1519 参数重放、Community plugins resolving a second @deepseek-ai/dsh-tools copy crash the tool scheduler with Cannot read properties of undefined (reading 'prepare') #1337 悬空调用、[BUG] 会话日志中一条 tool/result 引用了不存在的 call id，导致该会话所有请求被供应商 400 拒绝，永久不可用 #1593 孤儿结果——四条路径共享同一个修复核心：序列化前配对/净化校验 + 已中毒日志的修复通道。
• 根因新维度：这是损坏家族（seq 序号重复导致对话加载失败 #1333/BUG: 同一 DSH_HOME 下多进程并发写同一会话日志，导致 seq 重复、整段历史无法加载 #1452 跨进程、[bug] 会话历史加载失败：崩溃恢复与残留执行流并发写同一日志，seq 重叠（corrupt session log: seq gap in committed region） #1586 恢复 vs 存活、Bug: corrupt session log after unclean exit — replayed events cause seq gap in committed region, history unrecoverable #1497 重放、[Bug] A single corrupted session log prevents the whole workspace from booting (loader entry "workspace" fails to apply) #1473 坏帧）里第一个文件系统/IO 层机制——junction 改名与 O_APPEND 句柄并发。Windows 语义支持你的假设：目录 rename 时已打开的句柄保持有效、继续写旧文件；junction 就位后新建文件走新路径 → 同一 session id 两个物理文件，读写各指一边，撕裂事件（无 sourceEventSeqs + 未知 id）与物理交错一致。

修复排序（在你的 5 条之上补一层）

1. 序列化前配对校验（你的 #1）按 Bug + tested fix: truncated tool-call arguments permanently poison a session (llm-deepseek serializer) #1519 的样式做：serialize 前扫描 assistant tool_calls ↔ tool 消息 call id 差集，非法即 fail-fast 并给出"会话日志已损坏"的明确错误——至少把 400 换成可诊断的本地错误。
2. 已中毒日志的修复（你的 #2）——但形态要选对：家族立场（[bug] 会话历史加载失败：崩溃恢复与残留执行流并发写同一日志，seq 重叠（corrupt session log: seq gap in committed region） #1586/Plugin-written session events have no registration surface — a third-party plugin event makes whole session logs unloadable on rc.6 #1584 同款）是自动修复启发式会掩盖真实损坏。"把结果 id 修正为最近未应答调用"正是该放进显式修复工具（Add a session doctor and versioned migrations #1518 session-doctor 方向，dsh-doctor 离线侧已在做）的动作，加载时只检测+报告+隔离，不自动改写。
3. 修复 API（你的 #3）：assertToolResultRewrite 的 content-only 是刻意的溯源安全（surface 重写不得任意改写历史）——正确解是专门的 repair RPC（session-doctor），而不是放宽 surface 重写。
4. 目录保护（你的 #5）补一条廉价守卫：append 批次前校验"句柄指向的文件 == 当前路径解析的文件"（文件身份/inode 比对），rename/junction 后被检测到就拒绝写并报错——wellorbetter 的 writer-lease 补丁（[Bug] Cold history loading fully materializes large/corrupt logs and can stall the entire Web server #1550）管的是进程并发，管不到路径身份变更，两者互补。
5. UX（你的 #4）：与"损坏检测 → UI 提示"方向一致（Add a session doctor and versioned migrations #1518 也提了）。