工具调用 id 复用导致历史加载失败：兼容端点 callId 会话内不唯一，建议 UI 层加 turn/step 命名空间

[oevon364-ship-it]

问题现象 Symptom

加载某些历史会话时整段历史不可用，Web 端报：

历史加载失败:
conversation Context 9tool-call<id> received more than one start Match (internal)

多个会话同时受影响（同批会话），其余会话正常。数据本身完整：seq 连续、JSON 全部可解析、无并发写损坏迹象（不是 #1433/#1452/#1497 那种 seq 回绕）。

根因分析 Root Cause

受影响会话由 OpenAI-completions 兼容端点（非官方 API，走自定义网关/中转）生成。这类端点的 tool call id 是每轮响应内编号的局部 id：

step 1: tool/call callId="call_0" callId="call_1" callId="call_2"
step 2: tool/call callId="call_0" callId="call_1" callId="call_2"   ← 与 step 1 完全相同的 id
step 3: tool/call callId="call_0" ...

会话事件日志里 call_0 出现几十次，每次都是不同的工具调用（不同 step / 不同参数）。

而客户端 Conversation 引擎的 toolDefinition（packages/client/ui-conversation/src/client/conversation-nodes/tool.ts）用裸 callId 作为 Context 身份（conversationContextKey('tool-call', callId)）。同一会话内 callId 复用 → 同一个 Context 收到第二个 start Match → assembler 按设计 fail-loud 抛 more than one start Match → 整段历史拒绝加载。

官方 OpenAI API 的 tool call id 全局唯一（call_abc123...），所以官方端点从不触发；兼容端点不保证这一点，UI 层却假设了会话内唯一。

佐证

• 同一会话内 (turn, step, callId) 三元组零冲突（全部 64 个受影响会话验证过）
• 每个 tool/result 与前置 tool/call 的 turn/step 100% 一致（1488/1488 对）
• 数据文件本身无任何损坏（seq 连续、JSON 合法、zstd 帧完整）

修复方案 Fix

让 tool-call 的 Context 身份带上 turn/step 命名空间：裸 callId → ${turn}:${step}:${callId}。这样每轮的 call_0 变成 1:1:call_0、1:2:call_0、1:3:call_0…… 会话内天然唯一，且对已有历史数据零改动（key 是运行时派生的，不落盘）。

改动点：

1. packages/client/ui-conversation/src/client/conversation-nodes/tool.ts — toolDefinition.match 的 id 生成加 turn:step: 前缀（tool/call、tool/result 两个分支；tool/code-dispatch-* 分支在事件带坐标时同样加前缀，旧日志无坐标时回退裸 id 保持兼容）
2. packages/client/ui-trajectory/src/client/trajectory-tool-definition.ts — trajectory 视图的 trajectory-tool-call 同样处理（同类问题，不修的话 trajectory 面板会命中同一个重复 start）
3. packages/core/tools/src/code-mode.ts + types.ts — 数据侧：tool/code-dispatch-start / tool/code-dispatch 事件现在携带 root 调用的 turn/step（从会话日志里 root tool/call 事件拷贝），保证嵌套 dispatch 记录能与前缀化后的 root Context 配对。旧日志（无坐标）仍回退裸 rootCallId，不会崩
4. packages/client/ui-conversation/src/client/chat/tool-node-reader.ts — rootToolCall 由「按 key 精确查」改为「遍历匹配 root callId」，避免 key 格式变化后查询失配

为什么不改数据 / 不加锁

• 数据没有损坏，只是合法数据违反了 UI 层的唯一性假设——修 UI 层比修数据更根本
• 兼容端点的行为（每轮从 call_0 编号）无法从 DSH 侧改变，UI 层命名空间是唯一稳妥的根治点
• 历史文件零改动，修复即时生效，无需离线迁移

验证 Verification

• 全部 269 个持久化会话用真实 ConversationNodeAssembler + 修复后的 toolDefinition 加载：零失败（修复前 64 个抛 duplicate start）
• 单元测试：packages/client、packages/core/tools、packages/core/session 全量 3979/3979 通过（含 conversation-node-definitions、trajectory definitions、code-mode、assembler 测试）
• client typecheck 通过
• 重建 lib + web 产物后，浏览器实际加载的 /plugins/@deepseek-ai/dsh-client-ui-conversation/client.js 确认含前缀逻辑

关联

• #1333 / #1452 / #1497 是并发写导致的 seq 重复（数据损坏），本报告是兼容端点 callId 复用（数据合法、UI 假设失效）——两个不同根因，症状都是「历史不可加载」。建议官方在 UI 层对 tool-call 身份加 turn/step 命名空间，同时对兼容端点场景做防御。

---

作者：胡桃（胡桃的神秘小屋）