[Bug] Empty tool-call id ("") from adapters persists into the session log and refuses the whole session on load

[Semidia]

Summary

A degenerate model/adapter can emit a tool call with an empty id/name (tool-call-delta id:"" or a block-end payload carrying id:""). The harness persists it verbatim:

• BlockAssembler.assemble() falls back only via partial.toolCallId ?? CallId(...) — ?? does not catch "" (only undefined), and the block-end path (if (partial.block) return partial.block) bypasses the fallback entirely;
• AgentLoop.step / executeToolCalls write block.id straight into tool/call callId:"" and tool/result message.source.callId:"";
• on load, assertMessageEventShape requires a non-empty tool/result source.callId → the whole session log is refused (session event at seq N message must have tool source). A single bad event makes every previously recorded message unreachable.

Repro context

A polyglot provider streamed tool_call with empty id and name; the executor answered unknown tool ""; that empty callId was durably recorded; every subsequent load of the session failed with SessionPersistenceCorruptionError. The same corruption hit several sessions on our deployment.

Suggested fix (3 layers)

1. BlockAssembler.assemble() (packages/llm/llm/lib/types/assembler.js): fall back on empty string too:
   id: partial.toolCallId && partial.toolCallId.length > 0 ? partial.toolCallId : CallId(\call-${index}`)andname: partial.toolCallName && partial.toolCallName.length > 0 ? partial.toolCallName : 'unknown-tool'`.
2. BlockAssembler.blocks(): sanitize at the exit so direct block-end payloads are normalized as well (they currently skip the assemble() fallback).
3. AgentLoop.step (packages/core/agent-loop/lib/index.js): normalize tool-call blocks before writing assistant/message, so the assistant message, tool/call and tool/result all share one non-empty call id.

This prevents new bad data. Existing corrupted logs still need a one-off repair pass that assigns deterministic ids (call-<index> or similar) to the empty ids.

Happy to open a PR with the exact diff if useful.

[denial123789]

The prevention and historical-repair paths should stay separate here.

Normalizing an empty adapter ID before persistence prevents new damage. Repairing an existing log requires one deterministic replacement across the complete logical identity set: the assistant tool-call, tool/call, tool/result.message.source.callId, the result block toolCallId, and any related source-event references. A global empty-string replacement cannot preserve those invariants.

For an affected operator, stop the writer first, preserve the original artifact, decompress into a separate copy when needed, then locate the first invalid event and repair only a disposable copy with full replay validation.

I documented the relevant validation and recovery boundary here:

https://sandbaseai.github.io/deepseek-harness-handbook/session-log-durability.html

Canonical runbook: sandbaseai/deepseek-harness-handbook#22