【0.1.7-alpha.1】本轮运行失败format v4 message requires a producer-owned source kind

[anypwx]

使用DSH@v0.1.7-alpha.1版本，响应报错：format v4 message requires a producer-owned source kind
回退到DSH@v0.1.6-alpha.2版本是正常的，可以正常使用

[xixingya]

一样的，相同问题

[zhixiangjoy]

+1

[Ansonfishing]

补充一份定位 + 量化证据（Linux x64 / Node v24.16.0 / web profile / host 0.1.7-alpha.1）。同一个错误在客户端有两种表现，根因是同一条 retired-source 准入规则被放在了迁移链之前。

1. 抛出点

• @deepseek-ai/dsh-session-format-v3-to-v4/lib/index.js → source()：kind 必须是非空字符串且 !== "plugin"，否则抛 format v4 message requires a producer-owned source kind
• 包装层：@deepseek-ai/dsh-session-query/lib/index.js:515 → failed to observe session "<id>": …

2. 表现 A —— 本轮运行失败（写侧）

插件注入的消息仍带旧 wrapper，提交时被上面那道门拒掉 → 整轮失败。插件侧的同类 issue 已经在生态里各自开了（可交叉确认这不是单个插件）：

• omdsh-dev/DSH-better-sidebar#749
• SiriLee/dsh-rewind#34
• xmanrui/dsh-im#253
• volcengine/OpenViking#5291
• wowyuarm/dsh-agent-team#33、CNSeniorious000/dsh-generative-ui#24

3. 表现 B —— 升级前的历史会话全部打不开（读侧，本条新增证据）

文件名即格式世代（@deepseek-ai/dsh-session-format/lib/index.js:472）：

return generation === 0 ? "session.jsonl" : `session.v${generation}.jsonl`;

→ 0 代会话落在 session.jsonl.zstd；0.1.7 新写的落在 session.v4.jsonl.zstd。

扫描器逐行顺序（@deepseek-ai/dsh-session-persistence-jsonl/lib/index.js，SessionLogScanner.consumeEventLine）：

assertV4RowAdmission(decoded, KNOWN_SESSION_EVENT_TYPES);   // :1093 —— 先过 v4 准入门
…
this.restore.decodeRow(decoded);                            // —— 之后才跑 v0→v4 迁移

0 代行里的 0 代语法在门这里就被拒，restore 链（它存在的目的正是迁移这些行）没有机会执行。0.1.6 没有这道门，所以同一批文件在 0.1.6 下可读 —— 与 #6864（协议拒绝遗留 reasoning → 旧会话永久打不开）、#7133（v0→v1 迁移拒收 origin）属于同一类：新准入规则套在旧世代数据上，且没有迁移出口。

4. 量化（单台机器实测）

指标	值
含 legacy 语法的会话目录	2318
抽样 40 个 session.jsonl.zstd，逐行过 core 自己导出的 assertV4RowAdmission	40 / 40 拒准入
抽样 6 个今天新写的 session.v4.jsonl.zstd	0 拒准入（活跃会话完好）
违规行时间戳	全部 ≤ 2026-09-02；升级后写入 0 条 → 写侧无错，是读侧变严
两类 retired 语法	message.source.kind === "plugin"；retired header.system（format v4 request/header rejects retired header.system）
仅按 producerKind() 改写 kind 之后	只有 2 / 40 通过，其余仍卡在 header.system

单个 70928 行大会话里 289 条违规消息的 producer 分布：

tool-jobs 98 · acp-nudge 46 · compact 39 · @deepseek-ai/dsh-system-prompt 27 · dsh-mnemon 27
billion-context-dsh 23 · dsh-user-experience 16 · dsh-doublecheck 6 · repeat-tool-reminder 4
user-approval 2 · dsh-session-title-llm 1

其中一半是官方自己的生产者 → 这是历史数据，不是某个插件的锅。

5. 可复现 oracle（只读，不写盘）

// 用 core 自己导出的断言，避免自造规则造成误判
import { assertV4RowAdmission } from "file:///…/@deepseek-ai/dsh-session-format-v3-to-v4/lib/index.js";

for (const line of /* zstd -dc session.jsonl.zstd 的每一行 */) {
  try { assertV4RowAdmission(JSON.parse(line)); }
  catch (e) { /* 0 代行正是在这里被拒：本条即复现 */ }
}

抽样 40 个文件全部在此抛错；同一份内容按 producerKind() 改写后仍有 38 个抛 rejects retired header.system，说明手工改写不足以救回，需要 core 的完整迁移链。

6. 建议修法

1. 准入按文件世代判定：parseSessionFormatLogFilename(name) 得到 0/1/2/3 时走迁移，只有世代 ≥ 4 的文件才用 assertV4RowAdmission 硬拒；或
2. 把 assertV4RowAdmission 移到 restore.decodeRow() 之后，只对迁移产物断言 —— 那才是真正需要 producer-owned 的地方。

在当前实现下，任何在 0.1.7 之前产生过会话的用户都没有出口：dsh --help 没有会话迁移子命令，读路径也没有 legacy 容错分支。老历史是单向丢失，这比「本轮运行失败」更难被用户定位，所以一并写在这里。

[liupengf12]

我也遇到同样的问题，回退后让 DSH 自己倒查了一下原因：

症状

升级后能正常启动、能开会话、能发消息，但每一轮都失败：

本轮运行失败 format v4 message requires a producer-owned source kind

底层为 SessionFormatError: format v4 message requires a producer-owned source kind。

1. 报错来自哪里

0.1.7 新增了 @deepseek-ai/dsh-session-format-v3-to-v4（会话格式 V3 → V4）。它的消息 source 准入检查是（读自 0.1.7-alpha.1 的 npm tarball，运行时内联在 @deepseek-ai/dsh-session-persistence-jsonl 的 worker 中）：

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");

规则只有三条：

1. message.source 必须是 JSON 对象；
2. source.kind 必须是非空字符串；
3. source.kind 不能等于 "plugin"。

即 V3 时代的「插件包装」写法 { kind: "plugin", plugin: "<name>" } 在 V4 里被明确废弃。

2. 为什么"能启动但每轮任务失败"

v3 → v4 迁移只处理已经落盘的历史：该包 README 的 "Message-source conversion" 一节给了映射表，未知插件名会被改写成 plugin:<完整原名>，若干已知一方名字有固定映射。

但实时新产出的消息不走迁移，直接按 V4 校验。所以任何插件只要还在实发 kind: "plugin"，它的消息一进会话就被拒——症状正好是"启动、开会话、发消息都正常，一到本轮就失败"。

3. 我们环境里的违规产出方

是第三方插件 @openviking/dsh-memory-plugin（负责记忆召回/上下文注入）：

• 已装 0.3.0：注入消息时构造 source: { kind: "plugin", plugin: "openviking-memory", form }；
• 核对 npm 上最新的 0.5.0：同一写法仍在（capture.mjs），所以升级插件解决不了，0.1.0–0.5.0 全系列都是 V3 写法；
• 会话日志里能直接看到 9 条 "kind":"plugin","plugin":"openviking-memory" 记录。

对照之下，0.1.7 的一方包已经改完：@deepseek-ai/dsh-tool-jobs 发 kind: "tool-jobs"、@deepseek-ai/dsh-session-title-llm 发 kind: "dsh-session-title-llm"，抽检的几个一方包中已无 kind: "plugin" 站点。因此我倾向于认为：这不是核心回归，而是 V4 收紧了 source 契约、部分第三方插件还没跟上。

4. 一条命令自查你的环境

grep -rn 'kind: *"plugin"' ~/.dsh/profiles/*/node_modules --include=*.mjs --include=*.js

有输出 → 那个包就是打死每一轮的元凶。

也可以直接统计会话日志里的旧形态记录（0.1.6 写的是 session.v3.jsonl.zstd）：

for f in ~/.dsh/sessions/*/session-*/session.v*.jsonl.zstd; do zstd -dc "$f"; done 2>/dev/null \
  | grep -o '"kind":"plugin","plugin":"[^"]*"' | sort | uniq -c | sort -rn

5. 修法

让产出方改用 V4 的 kind：

• 写入侧：kind: "plugin" → kind: `plugin:${pluginName}`。这正是迁移为未知插件合成的形态，于是历史与新消息的 kind 一致；
• 读取侧：判定要同时接受 "plugin" 和 "plugin:<name>"，并且允许 plugin 字段缺省——因为迁移会把 plugin 字段丢掉、只留 kind。

围绕 @openviking/dsh-memory-plugin 我们按上面改了 4 处（1 处写入 + 3 处读侧判定）。说明：该改动逻辑上直接对上校验器，但我们是先降回 0.1.6 处理的，尚未在 0.1.7 上复跑验证，下次升级会复核。临时替代方案是卸载该插件（任务即不再失败），代价是失去它的记忆召回与捕获能力。

6. 顺带提醒：别把"启动失败"和这个错混在一起

我们还遇到两个与 source kind 无关的启动问题，症状都出现在"还没进入一轮对话"之前：

• dsh.profile.bundles 里写了 0.1.7 不存在的 bundle（我们的例子是 @deepseek-ai/dsh-experimental-agent-team-web-profile，最高只发到 0.1.6-alpha.2）→ 启动报 dsh: cannot resolve profile bundle ...；
• 旧实例仍占着 127.0.0.1:3080 时又发起新实例 → EADDRINUSE，在启动审计里表现为 webserver 激活失败。

7. 给维护者的一个小建议（可选）

现在这个报错只说"缺 producer-owned source kind"，不指出是哪个事件、哪个产出方。若诊断信息能带上事件类型 / seq / 原始 plugin 名（在可安全暴露的前提下），第三方插件用户定位会快很多；另外若迁移文档能加一节"插件作者在 V4 下如何声明自己的 source kind"，插件作者会更容易跟上。

[Hellovolcanoone]

所以是Openviking插件的问题？

[liupengf12]

是的，我卸载了 Openviking 插件后一切工作正常

[ZaynJarvis]

这是 ds 昨天发的 alpha 版，引入了插件侧不兼容更新，会影响所有相关 plugin，OpenViking 需要适配下

[baozbao]

这样搞 做插件的难受 用户也难受 哎

[bobcyw]

补一个不同角度的证据：这不是「某个插件坏了」，而是格式契约和插件扩展位之间的冲突。我们在一套本机定制上撞到了同一面墙。

现场：0.1.7 删掉共享的 kind: 'plugin' 之后，我们四个包各自给「持久化的消息来源联合」加了一个成员来替代它。
结果：持久化门禁判定「需要升到会话格式 v5」，而 v4 已经冻结 → 报的就是这个错。

想请教的是：插件要给这个联合扩展成员时，官方期望的做法是什么？

1. 有预留的扩展点（插件自带 producer kind 就能过门禁）——如果有，在哪儿声明？
2. 还是必须走正式流程升格式版本——如果是，插件作者该按什么顺序迁移（先声明 kind，还是先升格式）？

另外 #8094 里那条 source: { kind: "plugin", plugin: "hindsight" } 是同一个坑：第三方插件仍在发共享的 plugin kind，于是每一轮都过不去。

我们这边的完整清单（0.1.6 / 0.1.7 各 4 条，带出处）整理在 #8096。