[Bug] Chat history fails to load with providers that reuse tool-call ids ("received more than one start Match")

[zryyyyy]

标题：[Bug] Chat history fails to load with providers that reuse tool-call ids ("received more than one start Match")

要点：

现象：用 kimi-k3 等 id 按消息编号的模型时，打开历史/加载更早/直播中都会因 conversation Context 9:tool-calljob_output_0 received more than one start Match 崩溃，整窗只剩 Deep diving；数据未丢，纯客户端渲染崩溃
根因：tool.ts 的 match 用裸 callId 做 Context 键，假设了会话级唯一，但协议只保证单条消息内唯一（dsh-llm 自己的 call-${index} 兜底也同样如此）
复现：同一会话多个 step 调用同一工具 → 重新打开会话或点"加载更早" → 100% 复现
建议修复：Context 键改为 ::（tool/call 和 tool/result 都带 turn/step）；code-dispatch 事件无 turn/step，用按 seq 的最近调用索引归属；审批面板的 rootToolCall 反查改为扫描最新匹配节点
验证：真实崩溃日志 1226 条事件回放，旧逻辑立即崩溃，新逻辑全窗口+分页均零冲突、54 对调用/结果全配对
环境：dsh 0.1.0-rc.8 / macOS / kimi-k3，master 分支仍存在

[zryyyyy]

[Bug] Chat history fails to load with providers that reuse tool-call ids ("received more than one start Match")

Summary

The Web GUI's conversation assembler keys each tool-call conversation Context by the raw provider-issued callId. Some providers — e.g. Kimi (Moonshot) models, which emit ids like job_output_0, bash_0 — generate ids that are unique only within a single assistant message and repeat on every subsequent step/turn. When a session window contains two tool/call events with the same callId, the assembler's fail-loud invariant throws:

conversation Context 9:tool-calljob_output_0 received more than one start Match

Depending on which path hits it, the user sees:

• Open/resync (replaceWindow): the whole conversation fails to render — questions and replies all disappear, the view shows only the "Deep diving…" indicator, and a red banner "历史加载失败 / Failed to load history: … (internal)".
• "Load earlier" pagination (prepend): the page load throws; older history can never be loaded.
• Live append (append): the exception breaks live event processing mid-turn; the UI appears to lose records.

Records look "lost", but the durable session log is intact — it is purely a client-side rendering crash. It reproduces every time the duplicated callId falls inside the loaded window.

Root cause

packages/client/ui-chat/src/client/conversation-nodes/tool.ts (also packages/client/ui-trajectory/src/client/trajectory-tool-definition.ts):

match: (event) => {
  if (event.type === 'tool/call') return { id: String(event.data.callId), role: 'start' }
  ...
}

The Definition assumes callId is session-unique, but the LLM protocol only requires ids to be unique within one assistant message. dsh-llm's own BlockAssembler fallback (call-${index}) is also only message-unique. A Kimi session I tested had bash_0 recorded 24 times and job_output_0 7 times across steps, so history loading crashes 100% of the time for such sessions once the window covers two of them.

Reproduction

1. Use a provider whose tool-call ids are message-scoped (e.g. kimi-k3 / moonshot via the pi-ai/deepseek adapter).
2. Run a session where the same tool is called in multiple steps (e.g. repeated bash or job_output polling).
3. Reload the page / reopen the session, or click "加载更早" (Load earlier).
4. Observe the "received more than one start Match" failure and the blank conversation.

Minimal logic check over any such log: collect tool/call events, group by data.callId — any count > 1 crashes replaceWindow.

Suggested fix

Scope the Context identity by the coordinates that are unique per executed call. A step executes at most one assistant message, so <turn>:<step>:<callId> is unique, and both tool/call and tool/result durably carry turn/step:

if (event.type === 'tool/call')
  return { id: `${event.data.turn}:${event.data.step}:${String(event.data.callId)}`, role: 'start' }
if (event.type === 'tool/result' && isAppendSurfaceEvent(event))
  return { id: `${event.data.turn}:${event.data.step}:${String(event.data.message.source.callId)}`, role: 'update' }

tool/code-dispatch* events carry no turn/step; they can resolve their root through a small seq-ordered index of observed root calls (latest tool/call with that callId and seq < event.seq), falling back to the raw id when the root is outside the loaded window. The rootToolCall reverse lookup (approval panel) likewise needs to scan for the latest node whose root.callId matches instead of conversationContextKey('tool-call', rootCallId).

I verified this locally against a real failing session log (1226 events, 54 tool calls with heavy id reuse): the original matcher crashes immediately; the scoped matcher loads the full window and paginates all pages with zero invariant violations, and every result/dispatch still correlates onto its call (deterministic ids also let a prepended call heal a previously orphaned result).

Happy to share the full patch and the test scripts if useful.

Environment

• dsh 0.1.0-rc.8 (npm global install), macOS
• Provider/model: kimi-k3 (tool ids like job_output_0)
• Still present on master (packages/client/ui-chat/.../tool.ts, packages/client/ui-trajectory/.../trajectory-tool-definition.ts)