Bug: SessionFormatError "format v4 message requires a producer-owned source kind" - agent turns intermittently fail (core 0.1.7-rc.1)

[IegreSvolrO]

Summary

Agent turns intermittently fail with SessionFormatError: format v4 message requires a producer-owned source kind when the session persistence layer encodes an event. The session itself survives (later turns succeed), but the failed turn is lost and automatic title generation + projection cache writes also fail.

Environment

• DSH Desktop 2.0.14 (dsh-plugin-desktop), core 0.1.7-rc.1
• Windows 11 x64, Node v24.18.1
• Session storage: session.v4.jsonl.zstd (v4 format, zstd-compressed)

Symptom (host log)

[E] [dsh-agent-error] agent turn failed (session <id>, turn N, step 0/1): format v4 message requires a producer-owned source kind
[E] [dsh-agent-error] SessionFormatError: format v4 message requires a producer-owned source kind
    at source (…/node_modules/@deepseek-ai/dsh-session-format-v3-to-v4/lib/index.js:126:144)
    at assertV4SourceRowAdmission (…/dsh-session-format-v3-to-v4/lib/index.js:150:71)
    at assertV4RowAdmission (…/dsh-session-format-v3-to-v4/lib/index.js:1112:2)
    at Object.encodeEvent (…/dsh-session-format-v3-to-v4/lib/index.js:1097:3)
    at eventLine (… dsh-session-persistence-jsonl/lib/index.js:955:45)
    at eventLines (…/dsh-session-persistence-jsonl/lib/index.js:947:16)
    at Proxy.encodeEventBatch (…/dsh-session-persistence-jsonl/lib/index.js:3196:16)
    at Object.apply (…/cordis/lib/index.js:120:36)
    at Proxy.appendLines (…/dsh-session-persistence-jsonl/lib/index.js:3216:30)

Followed by:

[W] [session-title-service] automatic title generation failed: SessionFormatError: format v4 message requires a producer-owned source kind
[W] [session-projection-cache] session projection cache: turn/end write failed (cache stays stale): SessionFormatError: …

Observations

• Occurs on random hints of a random turn: in one session turns 1–3 (first hints right after session creation), then the same session works fine for many turns; in another session turns 10–11 failed, and the surrounding turns succeeded. It is not deterministic, and no single message type in the session log obviously differs from successful turns.
• Also reproduced on a session whose first turn failed with MISSING_CREDENTIAL (user had picked the deepseek-official provider without an API key configured): the failed turn's error-report write then hit the same SessionFormatError, masking the primary cause.
• Same core behavior in two independent runs of DSH Desktop 2.0.14 (core 0.1.7-rc.1).

Analysis / hypothesis

The error is raised by source() in dsh-session-format-v3-to-v4/lib/index.js:

• assertV4SourceRowAdmission (line ~142) only throws for messages whose source.kind === "plugin" (retired v3 wrapper syntax);
• assertV4MessageSources (line ~132) requires every durable message to have a non-empty source.kind that is not "plugin".

So at least one event being encoded contains a message with source.kind === "plugin" (or an empty/missing source) — most likely the agent-error report message written by dsh-agent-error (or an inbox splice produced by a plugin) which still uses the retired v3 { kind: "plugin", plugin: "…" } shape. Because the failure happens inside encodeEventBatch, the whole batch write fails and the primary turn error is swallowed (the log shows only the SessionFormatError, no earlier [E]).

Expected behavior

• A turn that fails for a real reason (network, missing credential, etc.) should record its error message in the session log even when that message originates from a plugin producer; the v4 admission check should either accept/adopt plugin-produced error messages or explicitly surface the offending event (seq + type) so the primary error is not masked.
• At minimum, the diagnostic should name the event/seq that failed admission instead of failing the whole batch silently.

Notes

• This is a release-candidate core (0.1.7-rc.1); happy to provide the zstd session file that reproduces it on request (it contains no credentials; provider names and session ids can be redacted).
• Search of existing issues found no prior report for SessionFormatError / "producer-owned source kind".

[PerryLink]

这条报错是 v4 有意拒绝"已退役的插件来源包装"——而你自己正好跑着一个桌面插件

1. 规则在这里，而且注释就写明了意图

packages/session/session-format-v3-to-v4/src/message-sources.ts:7-12：

function source(message: Readonly<Record<string, unknown>>): void {
  const value = message['source']
  if (!isSessionFormatJsonObject(value) || typeof value['kind'] !== 'string' || value['kind'].length === 0 || value['kind'] === 'plugin') {
    throw new SessionFormatError('format v4 message requires a producer-owned source kind')
  }
}

同文件第一行的模块注释是整件事的关键：

Native source admission preserves unknown attribution and refuses retired plugin wrappers.

⇒ 也就是说：kind 缺失/为空、或等于 'plugin'，都会被拒。'plugin' 不是"没写来源"，而是一个已经退役的来源形态——v4 明确不再接受它。你看到的不是"字段丢了"，而是"这种来源已经不被承认"。

2. 为什么是"写入时"炸，而且会连带标题与投影缓存

你贴的调用链 encodeEvent → assertV4RowAdmission → assertV4SourceRowAdmission → source 说明它发生在把事件编码持久化的时候——所以那一回合在落盘阶段失败。这恰好解释了你观察到的连带现象：自动标题生成与投影缓存写入也失败，因为它们走的是同一条编码路径。

会被检查的行类型（同文件 :32-35）是：user/message、system/message、assistant/message、tool/result、agent/inbox/spliced（查 inserted）、session/title-llm-request（查 messages）。⇒ 你可以据此缩小范围：是哪一类行带着 kind: 'plugin'。

3. 首要嫌疑：你环境里那个桌面插件

你的环境写的是 DSH Desktop 2.0.14（dsh-plugin-desktop），核是 0.1.7-rc.1。既然核现在拒绝插件自有的来源，那么"仍然按旧形态发 kind: 'plugin' 的包装层/插件"就会精确地产生这条错误。版本错配（桌面插件版本 vs 核版本）是这里最该先验证的一件事。

建议的判别实验（很便宜）：

1. 用普通 dsh web（不加载桌面插件）跑同样的操作——若不再复现，就锁定是那个包装层在发退役来源；
2. 或者把核降到与该插件匹配的版本再看是否消失；
3. 顺手确认 dsh-plugin-desktop 是否已针对 v4 更新过。

4. ⚠️ 升级核大概不能解决它

我核对了 0.1.7-rc.1 → 0.1.7-rc.2（你现在能装到的最新）之间对该目录的改动：只有发布提交与无关的 i18n/测试提交，message-sources.ts 的这条规则没有变。⇒ 也就是说：

• 这条规则在 rc.2 上依然存在；
• 光升级核不会修好它，因为要改的是产出方（发 kind: 'plugin' 的那个插件/包装层）。

5. 关于"间歇性"

"later turns succeed"与"只有部分回合失败"是自洽的：只有当某个事件里带上了退役来源的消息时才会炸。所以这也提示你去看发生失败的那些回合里，事件类型或调用方有什么共同点（例如都经过某个特定插件注入的消息）。

6. 一句话小结

这条错误本身诊断信息很完整：核在说"我不再接受 plugin 这种来源了"。所以正确的处置不是找核的 bug，而是让发消息的那一方改成 producer-owned 的来源——并且按第 3 步先确认是不是桌面插件。

[IegreSvolrO]

Resolved: producer was dsh-vision-router, fixed in v2.2.3

Not a core regression: the refusal rule is intentional and unchanged rc.1 → rc.2. In our case the offending rows (source.kind === "plugin") were written by dsh-vision-router@2.2.2 (11 call sites in its bundle). v2.2.3 explicitly recognizes session format v4 — upgrading the plugin fixes it, no settings migration.

Interim workaround while a producer is unpatched: reader-side tolerance in assertV4SourceRowAdmission (rewrite kind:"plugin" → a producer-owned kind instead of throwing); it lives in node_modules, so re-apply after each app update. Note: rows already persisted in session files keep failing on every encode even after the offending plugin is disabled — so removing the plugin alone does not recover existing sessions; only this tolerance (or cleaning the rows) fixes them, while upgrading the producer prevents new rows.

One genuine core-side improvement this surfaced: the error drops the whole batch without naming the offending event — include seq/row type/plugin so the producer is identifiable and the primary turn error is not masked.

[PerryLink]

你的结论与我核到的代码完全一致，而且你那条"核心侧改进"我能给出确切的落点

1. 先确认你的三条发现都对得上代码

• "拒绝规则是有意的、rc.1 → rc.2 未变" —— 我核过同一件事：message-sources.ts 的模块注释原文就是 "Native source admission preserves unknown attribution and refuses retired plugin wrappers"，而 rc.1 → rc.2 之间该文件没有改动（只有发布提交与无关的 i18n 提交）。⇒ 你"不是核心回归"的判断成立。
• "产出方是插件、升插件即修" —— 与"v4 只接受 producer-owned 来源"这一契约一致；dsh-vision-router@2.2.2 的 11 处调用点正是"仍在发 kind: 'plugin'"的产出方。
• "已落盘的行会一直失败，禁用插件也救不回既有会话" —— 这一点我也能确认：该检查发生在编码（encode）时，所以每次写事件都会重新校验到那条历史行，与"禁用产出方"无关。你这条比只升插件更完整，建议保留。

2. 你提的"核心侧改进"——落点就在那个 switch 上

你说错误"丢掉整批却不指名冒犯的那条事件"，并建议带上 seq / row type / plugin。这个建议在当前代码里是有现成位置的：

packages/session/session-format-v3-to-v4/src/message-sources.ts 的 assertV4SourceRowAdmission(row)：

if (!isSessionFormatJsonObject(row) || !isSessionFormatJsonObject(row['data'])) return   // :30
const messages = row['type'] === 'user/message' ? [data]                                  // :32  ← 已经知道 row type
  : row['type'] === 'system/message' || row['type'] === 'assistant/message' || row['type'] === 'tool/result' ? [data['message']]
    : row['type'] === 'agent/inbox/spliced' ? data['inserted']
      : row['type'] === 'session/title-llm-request' ? data['messages'] : []
…
if (isSessionFormatJsonObject(value) && value['kind'] === 'plugin') source(message)       // :40

⇒ 也就是说：这个函数已经拿到了整行 row（含 type），而真正抛错的 source()（:7-12）只看到单条 message。所以"把 row type 带进错误信息"不需要新增数据流——只需在 :40 那一处调用点把上下文一并传出。

建议把诉求写成：

在 assertV4SourceRowAdmission 触发 SessionFormatError 时，错误信息应包含该行的 type（必要时还有 seq）以及来源插件的标识，使产出方可被直接定位；现在它只说"需要一个 producer-owned 来源"，无法指出是哪一行、哪个插件。

这比"请提供更多信息"更容易被采纳——因为它连同"信息已经在该函数作用域内"这一点一起给出了。

3. 你那条临时规避的风险提示请务必保留

你写的"reader-side tolerance（把 kind:"plugin" 改写成 producer-owned）位于 node_modules，每次应用更新后要重做"，以及"只有改这里或清理那些行才能救回既有会话"——这两句是这条帖子里最容易被忽略、但对后来者最有用的部分。建议在正文里单独成段。

4. 版本提醒

⚠️ 当前最新就是 0.1.7-rc.2（tag dsh-v0.1.7-rc.2）⇒ 你的基线已经是最新。只是别把核换成 npm 的 latest（仍停在 0.1.5-rc.3，更旧）：

npm i -g @deepseek-ai/dsh@next

一条边界

我确认的是拒绝规则与 rc.1→rc.2 未变、检查发生在编码时、以及 :32-40 已持有 row type 这三点。dsh-vision-router@2.2.2 的具体调用点数量（11 处）与 v2.2.3 的修复以你的核对为准——我没有核对该插件。

[IegreSvolrO]

Thanks for the analysis — exactly what we needed. We filed the core-side feature request as you suggested (include row.type / seq / the source plugin id in the SessionFormatError, since the row context is already in scope at the call site), and kept the node_modules workaround warning as its own paragraph for anyone hitting this before producers are patched.

#8034