tool/result events with empty callId cause SessionPersistenceCorruptionError on resume

[zhangsheng377]

Bug Description

When resuming a session, DSH may fail with:

SessionPersistenceCorruptionError: stored session "session-xxx" failed validation: 
Error: session event at seq XXXXX message must have tool source

Investigation reveals that some tool/result events have source.callId = "" (empty string) and content[0].toolCallId = "", which fails the validator at dsh-session/lib/index.js:1265:

if (sourceRecord["kind"] !== "tool" || typeof sourceRecord["callId"] !== "string" || sourceRecord["callId"] === "") 
  throw new Error(`${subject} message must have tool source`);

All affected entries share the same pattern:

• error: { name: "ToolNotFoundError", code: "UNKNOWN_TOOL" }
• source: { kind: "tool", callId: "" }
• content[0]: { type: "tool-result", toolCallId: "", isError: true }

Root Cause

Two issues contribute:

1. Write path does not validate callId: When a ToolNotFoundError occurs, the toolErrorResult() function produces a result without a callId. The appendToolResult() → createToolResultMessage() path should propagate block.id, but in practice the callId arrives as an empty string. This likely happens when the LLM outputs a tool-call block with an empty or missing id field, and the write path accepts it without validation.

2. Read path strictly validates: The resume validator requires callId to be a non-empty string, creating a write-validate gap — data that was persisted cannot be loaded back.

Impact

• Sessions with affected events become permanently unresumable
• The corruption is silent at write time; users only discover it when trying to resume
• This has affected at least 3 sessions on my machine (4-5 bad entries each)

Suggested Fix

Option A (Write-side validation): Reject or sanitize tool-call blocks with empty id before persisting. If block.id is empty, generate a UUID so the event chain remains valid.

Option B (Read-side tolerance): When the validator encounters an empty callId on a ToolNotFoundError result, treat it as a known legacy format and fill in a synthetic callId instead of rejecting the entire session.

Option C (Both): Validate on write + tolerate on read for backwards compatibility with existing corrupted logs.

Workaround

I've built a repair tool that:

1. Scans all zstd frames in the session log
2. Finds tool/result entries with empty callId
3. Fills in recovered-{message.id} as the callId
4. Preserves the multi-frame zstd structure
5. Verifies the first frame remains a single header line

This repairs the session enough for DSH to resume it successfully.

Environment

• DSH version: 0.1.0-rc.7 → 0.1.1-rc.2
• OS: Windows 11
• Node.js: v22.x

[xiaoshenming]

和 #4240 / #4387 同一条：tool/result 的 source.callId === ""，重载时 assertMessageEventShape 整份 SessionPersistenceCorruptionError。

dsh-session-surgeon 现在不会给空 callId 编 UUID（会把后续 tool 对账修假）。inspect 能定位那条 seq。缺 message.id、seq gap、torn 可以 dry-run 修。

dsh plugin --profile web add "github:xiaoshenming/dsh-session-surgeon#main"

空 callId 还得官方写路径拒绝空 id，或提供正式修复口。