[BUG] Session history becomes unloadable ("corrupt") after a degenerate model tool call persists an empty callId

[alexzeng666]

Summary

When the model emits a degenerate tool call (empty callId and empty name), the harness executes it, gets ToolNotFoundError, and persists a tool/result event whose message.source.callId is "". On the next load, the session fails validation and the entire session history becomes unloadable from the Web GUI:

stored session "session-…" is corrupt: stored session "session-…" failed validation:
Error: session event at seq 850 message must have tool source

The write path produced a log that the read path refuses — a log written by the harness itself should always load back.

Evidence (minimal event pair from a real session log, v3 format)

// seq 849 — tool/call written from degenerate model output
{ "type": "tool/call", "seq": 849, "data": { "turn": 3, "step": 2, "callId": "", "name": "", "arguments": "{}" } }

// seq 850 — harness ran it, got ToolNotFoundError, persisted empty callId
{ "type": "tool/result", "seq": 850, "sourceEventSeqs": [849], "surfaceOp": "append",
  "data": { "turn": 3, "step": 2,
    "message": { "source": { "kind": "tool", "callId": "" },
                 "content": [{ "type": "tool-result", "toolCallId": "", "content": [ … ], "isError": true }],
                 "role": "user", "id": "…" },
    "error": { "name": "ToolNotFoundError", "code": "UNKNOWN_TOOL" } } }

The validator that refuses it: adoptSessionEvent → assertMessageEventShape (@deepseek-ai/dsh-session, "message must have tool source" — requires source.kind === "tool" with a non-empty callId), surfaced as SessionPersistenceCorruptionError by validateStoredEvents.

Expected behavior

Either:

1. Write-time guard — never persist an empty callId: synthesize a non-empty id (e.g. a UUID) for degenerate calls, or
2. Read-time tolerance — accept an empty callId on tool/result messages that carry data.error (they are produced by the harness's own error path, not by the model).

Reproduction

1. Use a channel/model that occasionally emits a tool call with empty callId/name (observed via a community gateway route).
2. Wait for the harness to execute it and persist the error result.
3. Reload the session history in the Web GUI → "历史加载失败 … corrupt", and the session can no longer be opened.

Workaround

Rewriting the log with a shared synthetic non-empty callId on both the tool/call and its tool/result (seqs, sourceEventSeqs and surface markers untouched) fully restores loading; the repaired log passes adoptSessionEvent + Session.fromRestore.

Environment

• Windows 11, DSH npm distribution (npx @deepseek-ai/dsh web), @deepseek-ai/dsh-session 0.1.5-rc.2, log format v3 (zstd framed JSONL).

Related

• "session-format-v0-to-v1 converter refuses loadable v0 sessions over cosmetic fields (history load breaks after upgrade to 0.1.5-rc.1)" — same symptom family (read path refuses a loadable session), different mechanism (this one is write-path/validation mismatch, not a version converter).

[PerryLink]

复核确认，校验点与你的报告一致：

• packages/core/session/src/index.ts:371-372：校验 tool 来源记录时，typeof sourceRecord['callId'] !== 'string' || sourceRecord['callId'] === '' 直接判非法。所以空 callId 的 tool/result 一旦落盘，下次加载整会话过不了校验 → "corrupt"。
• 机制链条：退化 tool call（空 callId/空 name）→ 执行得到 ToolNotFoundError → tool/result 以 callId "" 持久化 → 加载失败。与你的分析完全吻合。

修复方向（建议）：
① 在执行层拦截退化 tool call——空 callId 或空 name 时在持久化前拒绝或合成 id，别让非法记录进日志；
② 加载侧可考虑对空 callId 的 tolerance，或把该记录交给 repair 处理（packages/core/session/src/repair.ts 已有 pendingCalls 修补逻辑，可参考）。
诚实标注：加载侧 tolerance 目前不是现成功能，属建议；repair 是否覆盖空 callId 场景我未逐行验证。

恢复现有会话：备份后解压 session.v3.jsonl.zstd，删除/修复该 tool/call + tool/result 对（思路同 #6520 第 2 条的编辑恢复法），重压回。字节格式细节本轮未验证，操作前务必备份。