[Bug] Resume fails with SessionPersistenceCorruptionError after model emits a tool call with empty id/name; recovery notes + two related robustness gaps

[Zeaulo]

Environment

• dsh CLI: @deepseek-ai/dsh@0.1.1-rc.2 (npm global install; all inner @deepseek-ai/* packages also 0.1.1-rc.2)
• OS: Windows 10 x64
• Provider: OpenAI-compatible
• Model: deepseek-v4-flash-vision-exp, reasoning effort high
• Session scale when it broke: ~9.8k log events, turn 11→14, step input tokens ≈ 101k
• Interface: web UI (dsh web)

Summary

Two coupled problems:

1. Writer/loader asymmetry bricks resume. When the streamed assistant response contains a tool-call block whose id and name are empty strings (arguments fully populated), the harness persists this as-is (assistant/message block, tool/call event with callId:"", plus a synthesized tool/result error message whose source.callId is also ""). On the next resume, loader validation rejects exactly this record:

   internal: resume failed for session "session-…": SessionPersistenceCorruptionError:
   stored session "session-…" failed validation: Error: session event at seq NNNN message must have tool source
   

   assertMessageEventShape (packages/core/session/src/index.ts) requires every stored tool/result message to have source.kind === 'tool' with a non-empty string callId. So the writer happily stores state its own reader considers corrupt. During live operation nothing re-validates, so users only discover this later, at resume time.

2. Cascade 400 from the provider. Because history is replayed into subsequent requests, the empty function.name poisons every later request too — the following turns end with:

   invalid tool_call function, function/name/arguments cannot be empty  (HTTP 400, INVALID_REQUEST)
   

   This matches how it surfaced in the UI ("本轮运行失败").

Observed timeline (real session)

Event	What happened
turn 11	Stream yields tool-call block { id:"", name:"", arguments:"{...search-pattern...}" }; harness logs trio of corrupt events; turn ends OK
later resumes	SessionPersistenceCorruptionError on that tool/result
after manual data repair	user continues working
turn 14 (input ≈101k tokens)	same degenerate block appears again (arguments populated, id/name empty); same cascade 400 on the next request
turns 15–17	repeated retries keep failing until the relay account ran out of quota (unrelated to format)

The recurrence (twice in one day, different tools: one search-like call, one file-write call) suggests the trigger sits in the stream path — possibly the relay's SSE translation of tool_call deltas under long context, but the harness recording raw empties unguarded is what turns a glitch into persistent corruption.

Evidence (trimmed)

// seq A — persisted assistant message contains the degenerate block
{"type":"assistant/message","seq":160604,"data":{"message":{"role":"assistant",
  "content":[{"type":"reasoning", ...},{"type":"tool-call","id":"","name":"",
              "arguments":"{\"file_path\": \"D:\\\\...\", \"content\": \"...\"}"}]}}}
// seq B — call event passes through the empty ids
{"type":"tool/call","seq":160605,"data":{"callId":"","name":"","arguments":"{\"file_path\": ...}"}}
// seq C — synthesized error result carries empty callId → rejected by loader validation
{"type":"tool/result","seq":160606,"data":{"message":{"source":{"kind":"tool","callId":""},
  "content":[{"type":"tool-result","toolCallId":"","content":[{"type":"text","text":"Error: unknown tool \"\""}],"isError":true}]},
  "error":{"name":"ToolNotFoundError","code":"UNKNOWN_TOOL"}},"sourceEventSeqs":[160605]}

Rejected by (packages/core/session/src/index.ts, assertMessageEventShape):

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

Note: interruptedTurnClosers (packages/core/session/src/repair.ts) only repairs an open crash tail — it does not catch mid-log corruption like this, so there was no self-heal path.

How I recovered (for anyone hitting the same thing)

1. Locate the log: ~/.dsh/sessions/<slug-of-workspace-cwd>/<session-id>/session.jsonl.zstd.

2. Decompress (zstandard), rewrite the degenerate trio to self-consistent synthetic values,
   e.g. id/callId/toolCallId = "repaired-empty-call-<seq>", name = "__missing_tool__".
   All three must share one id: the assistant block id, the tool/call.callId,
   and the tool/result.message.source.callId + inner toolCallId.

3. Rebuild the artifact honoring the physical frame layout (this is important):

   • The .zstd file is a concatenation of independently compressed zstd frames.
   • Frame 1 must decompress to exactly one line — the header record ending with \n
     (enforced by assertZstdHeaderFrame / readFirstZstdLine,
     packages/session/session-persistence-jsonl/src/index.ts).
   • Remaining frames hold event batches; frames are written with the checksum flag enabled.
   • Re-compress: frame 1 = header line, frame 2 = all remaining events; e.g. via Node's
     zlib.zstdCompress(..., { params: { ZSTD_c_checksumFlag: 1 } }) or CLI equivalent zstd --check.

4. Restart dsh web before verifying — a running instance holds the prepared session in memory
   and will write stale state back over your repair.

Gotcha worth flagging: my first attempt re-encoded the whole log as ONE zstd frame. Resume-time
full reads would likely pass, but the sidebar listing path (readFirstZstdLine) hard-fails such a
file ("corrupt Zstandard session log: first frame is not exactly one header line"), and because …

Secondary finding: session listing has no per-item error isolation

… the enumeration that feeds the web sidebar runs without isolating per-session failures.
With just one unreadable log present, every workspace's session history disappeared from the
sidebar at once, silently. Moving the single offending directory away instantly restored all lists.
It would help to skip+warn per broken log instead of failing the whole listing, and/or expose a
validation/repair command for stored sessions.

Suggested fixes

1. Defensive ingestion sanitizer (preferred). Where stream deltas are materialized into
   tool-call blocks / call events, synthesize deterministic placeholders when id or name is
   missing (e.g. call-missing-<seq>, name __missing_tool__) before anything is appended.
   This keeps the durable log validator-valid AND keeps serialized history provider-valid
   (no more cascade INVALID_REQUEST on later turns); the model still sees an explicit
   unknown tool "__missing_tool__" outcome and can recover.
2. Alternatively/additionally, make interruptedTurnClosers-style repair handle mid-log
   degenerate trios, or provide an official dsh session doctor/repair command.
3. Listing isolation as described above.

[weijiafu14]

你的第 1 条（写入端存下了它自己的读取端认定为损坏的记录）是这份报告里最有价值的观察。补两件：那个"退化块"的来源可能不是模型，以及这个写读不对称属于哪个类。

一、id / name 为空，很可能不是模型发出来的——是累加器把好的值覆盖掉了

你的因果起点写的是"streamed assistant response contains a tool-call block whose id and name are empty strings"。这个社区里有一族报告指向另一种可能：模型发的是好的，是流式累加的过程把它弄坏的。

• #2979：后续 delta 携带 id:"" / name:null（而不是省略该字段），把先前已经收到的正确值覆盖掉。关键形状是"携带空值"而非"不携带"——任何"有字段就覆盖"的累加器都会踩；
• #725：同族，而且社区已经验证出了正确的守卫——typeof name === 'string' && name.length > 0（早期有人提的 (block.name ?? '') + name 拼接修法在 name: null 时会拼出 "lsnull"，被 @Constantine1916 和 @TAOLI123666 纠正）；@Electricitysheep 还把"null 隐式转字符串"的根因收进了手册；
• #885：同一根因的五份重复报告。

为什么这对你重要：如果起点是累加器，那么"模型偶尔会发退化块"这个前提就不成立，而你观察到的"turn 14 又出现同一个退化块"就有了更自然的解释——不是模型两次都犯同一个错，而是同一个累加器缺陷在同类报文上必然复现。

怎么验：看你会话日志里那次 assistant/chunk 序列（不是最终的 assistant/message）。如果早期的 delta 里 id/name 是有值的、后面某个 delta 带着空串/null 出现，那就坐实了是覆盖而非模型输出。你有 ~9.8k 事件的日志，这个应该能查。

（你的 provider 是"OpenAI-compatible"的第三方——这正是那一族报告的高发环境，因为各家网关对"字段不变时要不要重发"的处理不一致。）

二、你的第 1 条应该被单独提，它是一个通用的持久化缺陷

The writer happily stores state its own reader considers corrupt. During live operation nothing re-validates, so users only discover this later, at resume time.

这句话值得从这份报告里拎出来单独说，因为它与那个退化块是不是模型发的无关——无论坏数据从哪来，写入端都不该存下读取端会拒绝的记录。

而且这个形状在这个社区里已经有好几个亲戚：

帖	存进去的东西	读出来时
本帖 #4704	tool/result 的 source.callId 为空串	resume 时 assertMessageEventShape 判定损坏，会话打不开
#2915 / #1627 / #1703	截断时 replay state 与持久内容块数不一致	每次重放都被拒，会话永久无法继续
#740	中断留下带 tool_calls 却缺配套 tool 消息的历史	deriveMessages 忠实投影，每次请求都被 API 拒，会话报废

共同点：写入是宽松的、读取是严格的，而不一致的代价全部由用户承担，且总是在事后才显现。

建议把第 1 条提成一个独立条目，标题写成后果导向，例如 "Session writer accepts records its own loader rejects — corruption is only discovered at resume"。理由很实际：现在它挂在一个讲某个具体退化块的帖子里，很容易被修成"过滤掉空 callId"这一个特例，而下一个写读不对称照样会来。

（一个更根本的提法：写入路径应该用与加载路径同一套 schema 做校验，或者至少在写入时做一次同样的断言并 fail loud。这样坏数据在产生的那一刻就被发现，而不是几百个事件之后。）

三、你的第 2 条（级联 400）其实是第 1 条的下游

the empty function.name poisons every later request too

这一条和 #740 是同一个机制：一条不合规的历史进入持久层之后，之后每一次请求都会带上它。 所以它不需要单独修——只要第 1 条（别存进去）成立，级联就不会发生。值得在原帖里点明这个从属关系，免得被当成两个独立 bug 分头处理。

四、给现在被卡住的人

你提到"after manual data repair, user continues working"。补一句给搜到这帖的人：在修复合入前，唯一的自救就是手工编辑那条记录——但请先完整备份会话目录再动手，而且别只删那一条 tool/result：按你的描述，坏的是三件一套（assistant/message 里的块、tool/call 的 callId:""、以及那条 tool/result），只删其一可能触发另一个校验。

（更稳的做法是从坏掉那一轮之前分叉出一个新会话继续——这是 #1627 那边 @denial123789 对同类"会话被写坏"给出的建议，比手工编辑事件链安全。）

边界与利益相关

我们不修 DSH 自家组件——session persistence、assertMessageEventShape、流式累加都在 DSH 里。上面全是跨帖串联与提法建议；我没有复现过你这条，第一节的"可能是累加器"是一个待你用日志验证的假设，不是结论。引用的几帖都是别人的报告。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。这条不推销——会话一旦被写坏，装任何第三方插件都不会让它重新通过校验。

[denial123789]

I checked the reported writer/loader asymmetry against current 0.1.1-rc.2 (b150a55). The two boundaries still differ:

• restore/import reaches adoptSessionEvent() and assertMessageEventShape(), which rejects a tool/result whose source.callId is empty;
• live Session.append() snapshots JSON and validates surface placement, but does not call that message-shape assertion before publishing;
• the persistence coordinator checks supported vocabulary and contiguous sequence before writing, but does not add the missing non-empty call-id check.

So filtering the known empty continuation overwrite is necessary, but it is not the whole durability fix. A regression should also prove that the same invalid result is rejected before live append/persistence and after restore. interruptedTurnClosers() only closes an open tail; it does not repair an already committed invalid trio in the middle of the log.

For operators, avoid editing the live .zstd artifact: stop every writer, preserve and hash the complete Session directory, then continue in a fresh Session from independently verified workspace state. Manual repair should be isolated and version-aware because one logical identity spans the assistant block, tool/call, result source, and inner toolCallId.

I folded the source paths, correlated evidence set, safe containment, and regression gates into this independent runbook: https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/troubleshooting/streamed-tool-call-empty-identity.md

Affiliation: I maintain this SandBase handbook. It is an independent community project, not official DeepSeek AI documentation.

[nokkies]

This is two separate defects that happen to arrive together, and separating them matters because fixing either one alone still leaves you broken.

The empty id and the empty name have different causes

The empty id is the writer/loader asymmetry you describe (#4611 has the same shape). CallId is a branded string, so '' satisfies every type on the way in, and BlockAssembler synthesizes a call-<index> fallback only for an absent id — a ??, which "" sails straight through. One such record then fails the whole log at load, and the storage version is pinned, so there is no migration channel.

There is a second path that a fix at the assembler alone misses: block-end stores the adapter's block verbatim, bypassing the assembling fallback entirely. Both paths have to be covered, at the single point blocks leave the assembler, which also keeps the tool/call ↔ tool/result correlation the log's replayability depends on — that is why this wants fixing writer-side rather than by loosening the reader.

The empty name is not the same bug, and this is the part I would flag hardest: the id fallback does not help it. Synthesizing an id leaves you with a usable id and still no name, and an empty name is the fatal half — dispatch reports unknown tool "", the loop burns roughly ten steps, and the run exits 0 with an empty answer.

Its cause is in the OpenAI-compatible SSE translator. Standard streaming puts id and name on the first tool-call delta only; proxies in front of OpenAI-compatible endpoints commonly spell "no update" on later frames as an explicit null rather than by omitting the field. The translator tested !== undefined, so that null overwrote the identity captured moments earlier:

if (call.id !== undefined && call.id !== null) block.callId = call.id
const streamedName = call.function?.name
if (streamedName !== undefined && streamedName !== null) block.name = streamedName

with the delta type widened to string | null, which the same file already does for reasoning_content. Your provider being OpenAI-compatible rather than DeepSeek direct is consistent with this. #4671 covers it separately.

Why your session broke and a shorter one would not

Nothing here is scale-dependent — 9.8k events is not what did it. It needs one tool-call delta carrying an explicit null identity, which is a property of the proxy in front of the model, not of session length. That is worth knowing before anyone tries to reproduce it by running long.

Both are fixed locally, and the pair is the point: the id fix makes the log loadable again, the name fix is what stops the run silently producing nothing.

If it helps for recovery: since you confirmed the bytes are intact, the records are repairable in place — the correlation you need is that each tool/result's source.callId must match its tool/call, so assigning any unique non-empty id consistently across the pair restores loadability without inventing content.