Bug: dsh-agent-loop auto-continue notice messages lack message.id, corrupting session history

[coffeeaddicted-sfy]

Bug Description

The @deepseek-ai/dsh-agent-loop plugin, when auto-continuing after an empty reasoning-only response, injects a user/message with source.kind = plugin, form = notice, summary = "auto-continue on empty reasoning-only response" and content like 继续输出完整的分析与最终结论。 (continue output). These synthetic messages are written to the session log without a message.id (and without message.role/source on some paths).

The session validator (dsh-session, assertMessageEventShape) requires user/message / assistant/message / tool/result events to carry a non-empty message.id. A single missing id fails validation for the entire session, producing:

History unavailable for session "<session-id>": SessionPersistenceCorruptionError: stored session ... failed validation: Error: session event at seq NNNN lacks an identified message

Additionally, because dsh-workspace scans all session logs at startup (listArtifacts -> readFirstZstdLine), one corrupted session triggers the whole plugin tree load failure:

Error: dsh: plugin tree failed to load: ... corrupt Zstandard session log ...

Steps to Reproduce

1. Run dsh (v0.1.1-rc.2) in web mode.
2. Send a prompt that makes the model reply with reasoning-only content and no text output.
3. Observe the auto-continue kernel kick in (injects the notice message).
4. Restart dsh or open the session history in the UI.
5. The session fails validation with "lacks an identified message" at the injected event's seq.

We hit this twice in our environment (two different sessions, events at seq 2571 and seq 29082), confirming it reproduces on the same plugin notice path.

Expected Behavior

• Auto-continue notice messages should carry a valid message.id (and proper role/source) like every other injected message.
• The validator (assertMessageEventShape) should not fail the entire session for a single malformed injected event; ideally skip/repair notice-form events or surface them as warnings.

Actual Behavior

• An id-less user/message (form=notice) is persisted; the session becomes unopenable; dsh-workspace fails to boot when scanning the corrupted log.

Environment

• dsh (CLI): 0.1.1-rc.2 (@deepseek-ai/dsh-agent-loop 0.1.1-rc.2)
• Node.js: v24.19.0
• OS: Ubuntu 24.04 (Linux)
• Deployed via dsh web profile through systemd

Workaround we used

The session log is a multi-frame zstd file. We split frames by the zstd magic bytes, decompressed only the frame containing the offending event, patched in a UUID for the missing message.id, recompressed that single frame, and re-assembled the file. This preserves all events and passes validation. (Note: re-compressing the whole log as a single frame fails validation because assertZstdHeaderFrame requires the first frame to decompress to exactly one header line.)

Suggested Fix

In dsh-agent-loop, ensure the auto-continue notice message goes through the same message construction path as other injected messages (with id, role, source). In dsh-session, consider making the id requirement lenient for form: notice-type plugin events, or repair-on-read instead of fail-hard.

Related: session-event validation code lives in dsh-session/lib/types/index.js (assertMessageEventShape) and the log reader in dsh-session-persistence-jsonl (assertZstdHeaderFrame).

[liyangbing]

The missing identity is a real durable-boundary problem, but two source distinctions matter before fixing it.

First, I cannot find either auto-continue on empty reasoning-only response or the reported Chinese continuation text in the official rc.2 or current alpha.1 source tree. In the official contract, Agent.inject(), steer(), and followup() accept an already complete UserMessage; Agent Loop later appends that same message as user/message. The normal producer path is:

agent.inject(createUserMessage({
  content: [{ type: 'text', text }],
  source: { kind: 'plugin', plugin: 'the-producer', form: 'notice' },
}))

createUserMessage() supplies both the UUID and role: 'user'. A persisted source.kind: 'plugin' proves that a plugin-origin message entered the loop, not that dsh-agent-loop authored its content. The exact source.plugin, package version, installed bytes, summary, and text are the evidence needed to identify the producer.

Second, there is a core fail-late gap that explains how such a message can persist. rc.2 Session.append() snapshots JSON and validates request headers and the surface transition, but it does not call the cold-restore assertMessageEventShape(). Inbox validation only tests duplicate message.id values, so the first runtime undefined identity also passes. A JS plugin/cast/patched package can therefore write an id-less object into both agent/inbox/spliced and later user/message, then fail only at cold load.

I would fix both edges:

1. producer always calls createUserMessage();
2. Inbox admission or live Session append rejects an unidentified core message before committing it;
3. a regression test flushes and cold-restores the log, rather than ending after the live turn;
4. the diagnostic names the source/plugin while preserving the prior valid prefix.

I would not make restore silently skip notice-form messages. Identity correlates queue edits, claims, surface projection, and replay. Likewise, adding a UUID only to the final user/message is incomplete if the preceding agent/inbox/spliced.inserted[] contains the same malformed logical message. A format-aware repair must use one identity across every correlated occurrence.

There is also a separate physical boundary in the reported startup failure: listArtifacts() reads and validates only the independently compressed first/header frame. It does not parse later message ids. An id-less later event can make that Session fail full load, but cannot by itself make header-only listing report corrupt Zstandard session log. Recompressing the complete logical JSONL as one frame can create that second failure and widen the blast radius. Keeping the pre-repair bytes is therefore important.

I documented the exact source boundaries, evidence slice, safe quarantine route, correlated repair requirements, and regression gates here:
https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/troubleshooting/session-history-corruption-triage.md#failure-d-a-plugin-notice-bypasses-message-construction

[xiaoshenming]

这条报错（session event at seq N lacks an identified message）我们这边也踩过：官方 cold-restore 的 assertMessageEventShape 要求 user/message / assistant/message / tool/result 有非空 message.id，缺一条就整份拒读。runtime Session.append 当时不跑这道检查，所以插件注入能写进去、重启才爆。

dsh-session-surgeon 现在会把这种文件标成 message-missing-id，repair --apply 只补 id、不丢事件、不编 callId。先 dry-run 看 seq，再 apply（先 .bak.<utc>）：

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

这救的是已经落盘的坏日志。源头仍应让注入走 createUserMessage()（或等价地带上 UUID）。我们自己修过的样本是 source.kind=instruction-hint 的 plugin 注入，不一定是 dsh-agent-loop 本体——和楼上说的「先核对 source.plugin」一致。

「一条坏会话拖垮整个 plugin tree」是 workspace listArtifacts 扫 header 的连坐，把坏目录先移出 ~/.dsh/sessions 就能让 Web 起来；修文件是下一步。

[coffeeaddicted-sfy]

Thanks @liyangbing for the detailed analysis — the fail-late gap explanation (Session.append() snapshotting without calling assertMessageEventShape(), so an undefined id passes runtime writes and only fails on cold restore) matches exactly what we observed.

Direct evidence: the producer IS @deepseek-ai/dsh-agent-loop

In response to "I cannot find either auto-continue on empty reasoning-only response or the reported Chinese continuation text in the official rc.2 source" — we extracted the full persisted source metadata from all 8 affected events across 4 sessions (recovered from pre-repair backups):

{
  "kind": "plugin",
  "plugin": "@deepseek-ai/dsh-agent-loop",
  "form": "notice",
  "summary": "auto-continue on empty reasoning-only response"
}

Content: 继续输出完整的分析与最终结论。 ("continue and output the complete analysis and final conclusion")

All 8 events (seq 2571, 2884, 5499 in session-40a7295d; seq 29082 in session-18128277; seq 1799 in session-b7827389; seq 58, 193, 1327 in session-e87fae32) carry this exact source.plugin. Every one is type: user/message with an absent message.id (the id key is missing entirely, not empty).

So the auto-continue-on-empty-reasoning path in the installed @deepseek-ai/dsh-agent-loop (v0.1.1-rc.2, running inside dsh web on Node 24) persists a user/message whose message object is not constructed via createUserMessage() — no UUID, and (at least on the persisted events we saw) also missing role/source on the message object itself (the source metadata lives only in data.source).

This reproduces deterministically: any model reply that emits reasoning but no visible text triggers the auto-continue injection with the id-less message. We hit it 8 times across 4 sessions in ~24h.

What fixed it on our side

Frame-level surgery on the multi-frame zstd session log (split by magic bytes, rewrite only the frame containing the bad event, patch a UUID into message.id, reassemble) — preserves all events, keeps the first-frame header intact. A community member also shared dsh-session-surgeon which does the same job as a plugin.

Happy to provide anything else needed (installed package bytes, more samples, a minimal repro harness).