升个级为啥历史会话也用不了了？升级太草率了

[xiazemin]

历史加载失败：failed to observe session "session-3e51a685-d02d-4627-9126-2378c909ce59": @deepseek-ai/dsh-session-format-v0-to-v1 refuses this format v0 Session: user/message

[chen5410178]

历史加载失败：failed to observe session 我的也是这样的

[zczsw123]

这条的症状我这边也能复现，而且已经定位到具体闸门——补一点信息，免得后面搜到这条的人只看到"升级太草率"而没有出路。

环境：DSH Desktop 2.0.13 + 内核 0.1.5-rc.2，Windows 11。会话库 350 份，176 份是 v0 旧格式（session.jsonl.zstd，header version: 0），其中 115 份点不开。

报错长这样（与你的同类）：

SessionFormatUnsupportedError: subagent/descriptor 0 uses unsupported descriptor version 2;
source v0 artifact remains unchanged (raw log: …\session.jsonl.zstd)

这不是你的数据坏了，也不是升级"草率"——是迁移器的校验比运行时更严格，而且源文件一个字节都没动。 关键对照在内核源码里：

// dsh-session-format-v0-to-v1/lib/index.js:1586   迁移：版本不是 3 就 throw，整条历史判死
if (version === 0) throw new SessionFormatUnsupportedMigrationError(…)

// dsh-subagent/lib/index.js:1359                  运行时消费者：旧描述符直接忽略，会话照跑
if (version !== 3) return void 0;

消费者的态度是"这个字段我不用"；迁移的态度是"整条会话作废"。 我这边 115 份里 113 份都是这一个原因。

出路（重要）：本仓库 Discussions 里已经有一条把三类闸门全部拆开、并给出**已验证修复配方（0/49 → 49/49）**的帖子：

• 0.1.5-rc.1: v0→v3 迁移有三道 fail-closed 闸门 —— 49/123 之前的会话点不开（含没人报过的 inbox/spliced 一类），附已验证的修复配方 0/49→49/49 #6559 0.1.5-rc.1: v0→v3 迁移有三道 fail-closed 闸门 —— 49/123 之前的会话点不开…附已验证的修复配方
• 同一帖里 @Robin1987China 做了只读扫描器（不写任何文件），可以先定位再决定动不动手：npx dsh-session-check scan ~/.dsh/sessions

即：你的会话大概率没丢，只是被判死了；而且已经有工具能先告诉你"是哪一条、为什么"。 修之前请务必备份 sessions 目录——那套配方是逐帧改写，操作前先复制一份。

（另外提醒搜到本条的人：如果你是 Desktop 用户，升级还涉及 settings 迁移的另一类坑，见 anywhere-labs/dsh-desktop#1136。）

---

[xiaoshenming]

这一类（…session-format-v0-to-v1 refuses this format v0 Session: user/message …）报错尾巴会点名具体字段，先确认是哪一条闸门再动手，避免把文件改坏：

• … source summary requires notice form（或 sections require snapshot）→ 插件 source 的 form 与 summary/sections 不匹配（[Bug] v0→v1 迁移对单条不合规历史记录整体拒载，导致旧会话永久打不开 / Whole-log refusal on one non-conforming legacy record #6144 / 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）
• permission/preset … unexpected member → 旧写法多出 origin 之类成员（[BUG] 0.1.5-rc.1 会话历史永久无法加载:v0→v1 拒绝已发布的 v0 形状(permission/preset 带 origin) #6189）
• subagent/descriptor … unsupported descriptor version 2 → descriptor 版本落后（升级到 0.1.5 后，以前的一些老会话打不开了 #6151；多台机器统计里这是主因）
• assistant/message … chunk provenance is not one complete ordered attempt → 手工重编号后 sourceEventSeqs 没同步（# [BUG] 升级 dsh 0.1.5 后，此前手工重编号修复过的会话无法加载（chunk 溯源校验拒绝） #6348 / 更新0.1.5-rc.1后大部分会话打不开 #6175）

这些 dsh-session-surgeon 都有无损归一：不删事件、不发明 seq、不改代际。流程：先停写者 → inspect <id> 看 health → repair --dry-run 看每条要改什么 → --apply（先写 .bak.<utc>，可回滚）。每种形状都用官方 0.1.7-rc.1 的 sessionFormatV0ToV1 / sessionFormatV2ToV3 stage 对照过：修前拒、修后过；清单在仓库 README / CHANGELOG。

把完整的报错尾巴（省略号那段）贴出来，我可以确认是哪一条。

[zczsw123]

按你这条"先看报错尾巴点名哪个字段"的办法，我们这台机器上的分布可以对上一格。

环境 DSH Desktop 2.0.13 + 内核 0.1.5-rc.2，会话库 177 份 v0 工件，用内核迁移路径的同一调用判定（createRestore(header, { recovery: "recoverable", validation: "transformed" }) + 逐行 decodeRow + finish）：62 可加载 / 115 被拒。

被拒构成：

• subagent/descriptor N uses unsupported descriptor version 2 —— 113 / 115（N 有 0 / 5 / 6，不是单点写入）；
• released Session row … has seq gap —— 1 份；
• session/title-llm-request … messageSeqs targets consumed assistant/chunk … —— 1 份。

把 descriptor 的 data.version 归一到 3（成员形状不变）后，113 份逐份复验：修前拒、修后过，官方 v3 编码器也能完整写出全部事件。

顺带提醒后面搜到这条的人一个坑：官方 decodeRow() 会原地改写传入的行对象，所以"修前判一次、修后判一次"如果复用同一批对象会算出错误结论（我们实测：复用对象第二遍失败，而 JSON 层面只看得出 1 行变化，属性名/原型/Symbol 全无差异）。每一遍判定都要重新 JSON.parse。

再补一个可能影响定级的分布：本机 115 份被拒里 112 份是子代理子会话（侧栏不可见，也没有 projection 缓存），只有 2 份是顶层会话。所以"升级后历史会话全打不开"的体感，和"实际有多少份用户可见的会话打不开"是两个数 —— 后者是 2 份，而且恰好是上面那两类结构性问题。

[xiaoshenming]

两条补充，都在你这条线上：

• 被拒构成里 descriptor 占 113/115 这一格与我们这边一致；这类形状的写入者窗口是封闭的（dsh-subagent 从 0.1.2-alpha.2 起写的都是 3，已经没有还在写 2 的版本），所以它是一次性归一：只改 data.version 一个成员，其余字段原样保留，改完官方 v3 编码器能完整写出；同一 descriptor 上若还有别的越界成员，我们只报告、不继续猜。
• 你第 3 点那个坑（官方 restore.decodeRow() 原地改写入参，复用同一批对象会让第二遍判定静默出错）我们已经吃进工具链：探针每个入口点各自重新 JSON.parse 一份，测试在包能解析时端到端跑一遍。这条值得所有自建 dry-run / apply 流水线照做 —— 完整数据与讨论在 0.1.5-rc.1: v0→v3 迁移有三道 fail-closed 闸门 —— 49/123 之前的会话点不开（含没人报过的 inbox/spliced 一类），附已验证的修复配方 0/49→49/49 #6559。