An empty tool call (callId = "") makes an entire history session unreadable (SessionPersistenceCorruptionError)

[Hsia97]

Opening older history sessions in the Web UI (@deepseek-ai/dsh web, v0.1.1-rc.2, developer preview) fails with:

history unavailable for session "": SessionPersistenceCorruptionError: stored session "" failed validation: Error: session event at seq 237227 message must have tool source

Root cause (diagnosed from the persisted log)

The session log contains a single tool/result event produced by an empty tool call: the model emitted a tool call with an empty id/name, the dispatcher raised ToolNotFoundError: unknown tool "", and the writer persisted the failure with empty call ids:

{
  "type": "tool/result",
  "data": {
    "message": {
      "role": "user",
      "source": { "kind": "tool", "callId": "" },
      "content": [{
        "type": "tool-result",
        "toolCallId": "",
        "content": [{ "type": "text", "text": "Error: unknown tool \"\"" }],
        "isError": true
      }]
    },
    "error": { "name": "ToolNotFoundError", "code": "UNKNOWN_TOOL" }
  }
}

At load time assertMessageEventShape requires tool/result to carry a non-empty source.callId matching the preceding tool/call, so ONE such record rejects the entire session (hundreds of thousands of events). Restarting does not help — the bytes on disk are unchanged. There is no migration path: the storage format version is pinned to 0 and older records are hard-rejected.

Suggested fixes

1. Writer side: before persisting a tool/result for an empty tool call, generate a synthetic non-empty callId (or drop the failure record).
2. Reader side: tolerate/skip UNKNOWN_TOOL records with empty callId (warn, don't fail the whole session).
3. Add a storage-format migration/upgrade channel so old records are repaired instead of rejected at load.

Note

I already repaired the affected local sessions in place (backfilled unknown-tool-<seq> callIds on the tool/call + tool/result pair, re-encoded with the same zstd framing) and all affected sessions load again — the underlying data was intact; this is purely a validation/schema-drift issue. Happy to contribute the writer-side guard (or reader-side tolerance) as a PR if maintainers agree on an approach.

Environment: Windows 10 22H2 (build 19045, 64-bit) · Node v24.13.0 · npm 11.12.1 · @deepseek-ai/dsh@0.1.1-rc.2 (npm global).

[nokkies]

Confirmed, and your diagnosis holds all the way down. Thank you for repairing your own logs and reporting that the bytes were intact — that is what makes this unambiguously a validation asymmetry rather than data loss.

Where the empty id gets in

BlockAssembler already synthesizes an id, but only for an absent one:

id: partial.toolCallId ?? CallId(`call-${index}`)

CallId is a branded string, so '' satisfies every type on the way in, and ?? never fires for it. A provider that emits "" rather than omitting the field sails straight through into tool/call and tool/result, and the reader then rejects the whole log.

Fix, writer-side

Treat empty exactly like absent, at the single point blocks leave the assembler:

function withCallId(block: ContentBlock, index: number): ContentBlock {
  if (block.type !== 'tool-call' || block.id !== '') return block
  return { ...block, id: CallId(`call-${index}`) }
}

There is a second path that is easy to miss — I missed it on the first attempt. block-end stores the adapter's block verbatim, so a block handed over complete that way never reaches the assembling fallback at all. Applying the normalization where blocks are read out covers both the streamed partial and the block-end case; patching only the ?? leaves half the hole open.

On your suggestion 2 (reader-side tolerance)

I would argue against loosening the reader, and for the writer fix alone. The correlation between tool/call and tool/result is what makes the log replayable; synthesizing an id keeps the pair correlated, whereas tolerating an empty callId admits genuinely broken pairs that no longer identify each other. Your suggestion 1 is the one I would take.

Your suggestion 3 (a migration channel) stays the open question — this fix stops new logs from being damaged but does nothing for the ones already on disk, which still need the in-place repair you describe.

Related but separate

#4671 looks like the same bug and is not: there an adapter discards the id and the name when continuation frames send explicit nulls. The assembler fallback above does not help it, because it restores an id while the empty name is what makes dispatch fail with unknown tool "". Two fixes, two places.

[weijiafu14]

Session-unreadability is the nastiest tail of a well-measured family — cross-adapter datapoint:

We fault-injected the real pi-ai openai-completions accumulator (client/SSE parser/assembly unmodified; only the wire bytes synthetic) with this exact delta family — empty-string id/name continuations, late identity, parallel calls with no ids at all (index-keyed interleave), and index-less id-keyed deltas: all assemble correctly. The semantics that make it immune: blocks are keyed by index first, and the first non-empty id/name wins — a later empty/null value cannot overwrite. Re-verified on latest pi-ai 0.84.4. Per-case verdicts: accumulator-experiment.mjs / results; live two-call turn with distinct non-empty ids on real api.deepseek.com: provider-threads-e2e.json.

That measured rule (index-first keying + first-non-empty-wins) is a ready-made semantic for the llm-deepseek fix — several sibling reports converge on it (#3090 has the deepest diagnosis; #2674 the session-history angle). Scope honesty: this doesn't patch llm-deepseek; until it lands, a custom declaration routed through llm-pi-ai rides the immune accumulator (recipe). One known limit of that path for fairness: two calls sharing one index DO merge there — filed upstream as earendil-works/pi#8861.