[Bug] History loading fails with "received more than one start Match" when tool call ids are not globally unique

[Prayermoon]

[Bug] History loading fails with "received more than one start Match" when tool call ids are not globally unique

Summary

Loading a session history window that spans multiple steps/turns fails in the web client with:

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

The root cause is that the "tool-call" conversation context key is derived from the bare callId (conversationContextKey("tool-call", callId)), which assumes tool call ids are globally unique within a session. This assumption does not hold when the model is served through a third-party OpenAI-compatible gateway that renumbers tool call ids per request (call_0, call_1, ...). The same call_0 then appears in multiple steps/turns, and the second start match for the same context key throws during replaceWindow history loading.

Environment

• @deepseek-ai/dsh 0.1.0-rc.6 (verified present in rc.7 and current master as well — see below)
• Web client, history window spanning more than one step/turn

Repro / Triggering mechanism

1. Any session accumulates several steps in one turn (or several turns), each step emitting tool/call events.
2. The model endpoint is a third-party OpenAI-compatible gateway that assigns per-request tool call ids like call_0, call_1, restarting from call_0 on every request. (OpenAI-compatible responses carry id in the tool call blocks; the gateway reuses short sequential ids instead of globally unique ones.)
3. Open the session (or load an older history window). replaceWindow feeds every event in the window into the conversation context engine. The second tool/call whose callId is call_0 (from a different step/turn) hits acceptMatch with role: "start" for the already-started context key 9:tool-callcall_0, which throws:
   conversation Context 9:tool-callcall_0 received more than one start Match.

Note the same collision can also occur within a single turn: call ids restart per step, so call_0 legitimately repeats across steps.

Affected code

packages/client/ui-conversation/src/client/conversation-nodes/tool.ts (and the same pattern in packages/client/ui-trajectory/src/client/...):

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

The context key is built from id alone; tool/call events already carry turn and step in their data, but they are not part of the key.

Suggested fix

Scope the tool-call context key by turn and step so each (turn, step, callId) combination gets a unique context:

• tool/call → id: ${event.data.turn}:${event.data.step}:${callId}``
• tool/result → same prefix (tool/result pairs with tool/call in the same step)

The rootToolCall(snapshot, rootCallId) helper (used by approval frames that carry only the bare callId) should fall back to scanning materialized tool-call nodes when the direct key lookup misses.

We have verified this fix locally: a session with 8 turns / 80 tool calls that previously produced 78 collisions loads cleanly with 0 conflicts, and the previously failing history windows now load.

Additional note

This only manifests with endpoints that reuse tool call ids across requests. With endpoints that issue globally unique tool call ids (e.g. the official API), the bug is latent and does not surface, which is likely why it has not been observed upstream.

Happy to open a PR with the fix if that is helpful.

---

9. Disclaimer: The above content is AI-generated, and the submitter has no IT background. Please treat it as reference only.

[denial123789]

The rc.7 replay path supports this diagnosis. replaceWindow() sorts the loaded entries, rebuilds its location index, and matches every input again. The tool conversation definition starts a context from String(event.data.callId), while the root node already records turn and step. A gateway that restarts at call_0 can therefore make a physically and logically valid log fail only during client projection.

Before changing durable data, a useful proof is to group root tool/call events by bare callId while retaining (turn, step, seq). Multiple starts for the same id across steps, plus a clean A/B result through a provider that emits globally unique IDs, isolates the projection boundary.

Scoping the identity needs to be end-to-end: call and result matches must derive the same composite key, and approval/root lookup paths that only carry the bare call id need an unambiguous fallback. Regression cases should cover reuse across turns, reuse across steps in one turn, nested calls, approvals, partial history windows, and live append after replay.

I added a source-pinned triage map that distinguishes this from frame and sequence corruption: https://sandbaseai.github.io/deepseek-harness-handbook/session-history-recovery.html

Disclosure: independent SandBase community handbook, not official DeepSeek documentation.