升级到 0.1.5 后，以前的一些老会话打不开了

[MWGE22629]

一直在用dsh，很喜欢。遇到一个问题想反馈一下。

问题

从 0.1.1 升级到 0.1.5 之后，一些以前的会话打不开了。网页上提示 failed to observe session ... refuses this format v0 Session，意思是不认这个旧格式。我这边 35 个会话里有 15 个打不开。

原因

看起来是新版把老会话升级成新格式的时候检查得太严了——只要是老版本当时写进去、现在不再用的字段，整份会话就直接不给加载。

而且它一次只报一个错，改掉一个又冒出下一个，我一共碰上四种：

1. 老版本的权限设置里多了个 origin 字段，新版不认，报错。（新版其实已经不用这个字段了，直接忽略掉就行）
2. 子代理的记录是老格式 version: 2，新版只认 3，报错。（这两种格式的字段其实是一样的，当成 3 应该就行）
3. 插件自己加的消息来源类型（比如 instruction-hint、at-file-mention），新版不认，报错。
4. 以前用 dsh-chat-import 导入的会话，开头有个 session/imported 标记，新版不认。

建议

老版本自己写进去的数据，希望新版能兼容一下：能忽略的就忽略，能直接升级的就升级，不要因为一个字段就让整个会话打不开。

或者至少给个修复的命令，不然这些老会话就永远看不了了。

环境：dsh 0.1.5-rc.1，Windows 11，Node v24.4.1。

再次感谢！

[PerryLink]

你这四类报错我在 0.1.5-rc.1 的源码里都定位到了. 它们不是同一条规则, 但属于同一类问题: 迁移器把「released v0 写入器当年允许写」当成了「今天必须能读」的硬条件.

你遇到的	触发规则	源码位置
权限设置多了 origin	permission/preset 的成员表只允许 preset, 多一个成员即被拒(另: header 里 origin 若存在, 只允许字面量 subagent)	payload-validation.ts:210 + dispositions.ts:76; 另一处是 validation.ts:20, 58-59 与 codec.ts:22, 171-172
子代理 version: 2	version 只接受字面量 3	payload-validation.ts:956
instruction-hint / at-file-mention	kind 分支与 plugin 的 form 字面量都是封闭集合(form 仅 6 个值); 这两个串在当前代码树里不存在, 属第三方自造变体	payload-validation.ts:643, 分派见 539-631
session/imported	未知历史事件类型一律拒绝, 且该记录自带 ignorable: true 也照拒	validation.ts:117-122

最后一行值得单独看一眼: 报错原文就是 migration refuses unknown historical events even when ignorable. 也就是说旧日志自己声明了「这条可以忽略」, 迁移器仍然整份拒载 —— 这正是你说的「一次只报一个、改完又冒下一个」的来源: 校验逐条抛出、整份中止.

机制的完整说明(以及「该不该放宽、放宽后诊断落在哪」)我写在 #6144 里了, 它和你是同一个问题, 只是触发字段不同. 这里不重复.

关于你自己救这些会话, 路径本身可行, 三个注意点:

1. 先备份 .bak, 并保留原有 zstd 帧结构, 不要重新整体压缩;
2. 改完用官方自己的只读入口复验: createRestore(header, { recovery: 'strict', validation: 'transformed' }) —— 它过一遍就说明改后确实可载入, 不必靠重启 dsh 试;
3. 第 2 类(子代理 version: 2)如果确认字段与 3 一致, 直接改成 3 即可; 但同一条记录里若还有别的越界成员, 会接着报下一个 —— 建议一次性把该记录的成员按上表过一遍再写回, 省得反复开 dsh.

范围说明: 以上都是在 0.1.5-rc.1 源码上静态定位的结果, 我没有在你这类混合语料的会话库上实跑迁移.

[yunos1]

我的直接没法开新对话了，工作区也选不了

[EverOnce]

.dsh中的session文件zstd帧格式不兼容，用dsh修复大师workbuddy跑修复吧，可以把老session找回来，已试过可行

[EverOnce]

还有就是把dsh-at-file插件卸了，dsh新版自带了at-file-mention

[xiaoshenming]

四类里的三类我们已经跟进并修了（dsh-session-surgeon，commit 519ea4d）：

• permission/preset 多 origin（与 [BUG] 0.1.5-rc.1 会话历史永久无法加载:v0→v1 拒绝已发布的 v0 形状(permission/preset 带 origin) #6189 同因）→ 只保留 preset，权限语义不变
• subagent/descriptor version 2 → 3（两个版本字段一致，直接改 3）
• 插件消息来源 summary/sections 与 form 不匹配（与 session-format-v0-to-v1 converter refuses loadable v0 sessions over cosmetic fields (history load breaks after upgrade to 0.1.5-rc.1) #6194 同因）→ 补对应 form 或只去展示用成员，正文不动

session/imported 和插件自己的消息来源类型（instruction-hint、at-file-mention）属于「冻结 v0 清单外的类型」：官方迁移连 ignorable: true 都拒。我们不会删事件、也不会编类型，inspect 会把 seq 列出来，等官方扩清单。

工具只在本机 runtime 自己会跑 v0→v1 迁移（format ≥ 1）时才改文件；四类形状都用官方 0.1.5-rc.1 的 sessionFormatV0ToV1 逐条验证过：修前拒读、修后干净迁移。--apply 先写 .bak.<utc>。另外 zstd 帧本身没坏（楼上「帧格式不兼容」的说法不成立），拒载发生在 payload 校验层。

没装插件的话：

npx --yes github:xiaoshenming/dsh-session-surgeon repair <会话id>          # 先看会改什么
npx --yes github:xiaoshenming/dsh-session-surgeon repair <会话id> --apply  # 确认后再写回

[woosh2010]

补一个读取侧修复的思路，和楼里已有的"改写会话数据"方案互补。

楼里目前的方向都是改用户文件（dsh-session-surgeon 那类，改前留 .bak）。这能立刻自救，
但每个受影响的人都要跑一遍，而且动的是原件。这里拒读的其实是官方自己写出来的数据，
所以更该修的是迁移器——修一次，全部会话（含以后重读）都能正常打开，且不碰任何会话数据。

两处都在 packages/session/session-format-v0-to-v1/src/：

1. dispositions.ts:76 漏了 origin。0.1.1-rc.1 的写入点就是
   session.append('permission/preset', { preset, origin })，取值恰好三个：
   default / inferred / selection（0.1.2-alpha.2 起移除）。
2. payload-validation.ts:956 硬要求 version === 3，但 0.1.1-rc.1 的
   SUBAGENT_DESCRIPTOR_VERSION = 2。

关于第 2 点，补充一处精确化：楼上说"两个版本字段一致"，更准确的是——
v3 相对 v2 只多了一个可选字段 agentReasoningEffort：

v2 continuable: version, mode, provider, label, agentProvider, agentModel, persona, toolFilter
v3 continuable: version, mode, provider, label, agentProvider, agentModel, agentReasoningEffort, persona, toolFilter

也就是说 v2 描述符恰好等于省略该字段的 v3 描述符。因此升版本号是严格无损的，
可以放心并入既有的 normalizeLegacy* 链（该链在 assertReleasedEventPayload 之前执行，
本就是为这类差异预留的扩展点），不必继续硬拒。

我按上面三处改了 0.1.5-rc.2 的构建产物，用真实生产读取路径
（createRestore → decodeRow → finish，即完整 v0→v1→v2→v3 + 当前格式校验）
跑本机 57 个会话日志：修前 1/57，修后 57/57。迁移结果的语义也核对过：
origin 原样保留，descriptor 升到 3 之后 provider/label/agentProvider/agentModel
一个不少。

复现脚本（不需要任何受影响的会话数据，干净 npm i 就能跑出这两个报错，
另含一个不带 origin 的对照组以排除"样例本身有问题"）：

mkdir repro && cd repro && npm init -y
npm i @deepseek-ai/dsh-session-format-catalog@0.1.5-rc.2
node repro.mjs

import { sessionFormatCatalog } from "@deepseek-ai/dsh-session-format-catalog";

const HEADER = {
  type: "session", version: 0,
  id: "session-00000000-0000-0000-0000-000000000000",
  createdAt: 1789000000000, delegationDepth: 0,
};

function restore(rows) {
  const session = sessionFormatCatalog.createRestore(rows[0], {
    recovery: "strict", validation: "current",
  });
  for (let i = 1; i < rows.length; i += 1) session.decodeRow(rows[i]);
  return session.finish();
}

const CASES = {
  "1. permission/preset carrying `origin`": [
    HEADER,
    { type: "permission/preset", seq: 0, time: 1789000000000,
      data: { preset: "workspace-write", origin: "default" } },
  ],
  "2. subagent/descriptor at version 2": [
    HEADER,
    { type: "subagent/descriptor", seq: 0, time: 1789000000000,
      data: { version: 2, mode: "continuable", provider: "spawn", label: "repro",
              agentProvider: "deepseek-official", agentModel: "deepseek-v4-pro" } },
  ],
  "3. control: permission/preset without `origin`": [
    HEADER,
    { type: "permission/preset", seq: 0, time: 1789000000000,
      data: { preset: "workspace-write" } },
  ],
};

for (const [name, rows] of Object.entries(CASES)) {
  try { const a = restore(rows); console.log(`PASS  ${name} -> v${a.header.version}`); }
  catch (e) { console.log(`FAIL  ${name}\n      ${e.constructor.name}: ${e.message}`); }
}

0.1.5-rc.2 上的实测输出：

FAIL  1. permission/preset carrying `origin`
      SessionFormatUnsupportedMigrationError: @deepseek-ai/dsh-session-format-v0-to-v1
      refuses this format v0 Session: permission/preset 0 data has unexpected member "origin"
FAIL  2. subagent/descriptor at version 2
      SessionFormatUnsupportedMigrationError: subagent/descriptor 0 uses unsupported
      descriptor version 2
PASS  3. control: permission/preset without `origin` -> v3

顺带确认一下：master 上这三处目前仍是原状（dispositions.ts:76、
payload-validation.ts:956、migration.ts 的归一化链），所以这个问题不会随
升级自行消失。楼主提的另外两类（插件消息来源、session/imported）不在上面两处之内，
需要各自单独处理——这里只覆盖我实测过的两类。

本地补丁（仅为验证用，不是让官方照抄这个文件）

补在 @deepseek-ai/dsh-session-format-v0-to-v1/lib/index.js（0.1.5-rc.2 构建产物）：

-	"permission/preset": disposition(["preset"]),
+	"permission/preset": disposition(["preset"], ["origin"]),

 		case "permission/preset":
 			nonEmptyString(data["preset"], `${label} preset`);
+			if (data["origin"] !== void 0) literalValue(data["origin"], [
+				"default", "inferred", "selection"
+			], `${label} origin`);
 			return;

+function normalizeLegacySubagentDescriptor(event) {
+	if (event.type !== "subagent/descriptor" || event.data?.["version"] !== 2) return event;
+	return { ...event, data: { ...event.data, version: 3 } };
+}
+
 function normalizeReleasedV0Event(event, sessionId, state) {
-	const message = normalizeLegacyMessage(normalizeLegacyCompaction(
+	const message = normalizeLegacySubagentDescriptor(normalizeLegacyMessage(normalizeLegacyCompaction(
 	...
-	), sessionId, state.messageIds);
+	), sessionId, state.messageIds));

该包被整条迁移链共享（v1-to-v2 从这里 import RELEASED_V0_EVENT_DISPOSITIONS
与 assertReleasedEventPayload，v2-to-v3 从这里 import
assertReleasedPayloadSemantics），所以只需改这一个包。