Alpha(0.1.2-alpha.2) 写盘的区间 sourceEventSeqs 导致 rc.2(0.1.1-rc.2) 加载会话报 SessionPersistenceCorruptionError

[pmZiLong]

一句话说明错误结果：

Alpha 版本（@deepseek-ai/dsh-session@0.1.2-alpha.2）把 sourceEventSeqs 写成新的区间格式（如 [[1331,1424]]），而当前仍在运行的 rc.2（0.1.1-rc.2）读取端不识别该格式，导致升级后会话历史加载直接报 SessionPersistenceCorruptionError（history unavailable）。

复现、预期与验收

复现步骤

1. 使用 Alpha 版本（@deepseek-ai/dsh@0.1.2-alpha.2）运行并产生一段对话（生成多个连续 chunk，例如一次输出 94+ 个 assistant/chunk）。
2. 保持同一会话，随后用 rc.2（0.1.1-rc.2）版本（如 npm i -g @deepseek-ai/dsh 装的 latest 标签实际是 rc.2）加载/打开该会话历史。
3. 会话读取失败，GUI 提示 history unavailable for session ...。

实际结果
读取端校验抛错（可复现于 dsh-session 的 assertProvenance）：

SessionPersistenceCorruptionError: stored session "..."
failed validation: Error: invalid seed event at index 1425:
session event "assistant/message" sourceEventSeqs must densely contain non-negative safe integers

底层原因：Alpha 的持久化写入端 dsh-session-persistence-jsonl 在 encodeProvenanceForStorage 中用 encodeSeqRanges 把连续的 chunk 序号压缩成 [start, end] 区间对（[1331,1324,...] → [[1331,1424]]）；读取端 rc.2 的校验只接受扁平整数，遇到区间数组 [1331,1424]（非整数）即判定损坏。而 Alpha 自身的读取端 expandProvenanceFromStorage → decodeSeqRanges 是能展开回去的，说明这是写盘端与读盘端格式不匹配。

预期结果

• Alpha 与 rc.2 不应在磁盘格式上不兼容到“静默判定损坏”的地步；或者
• 磁盘格式应带版本号，旧读取端遇到新格式时给出明确的“请升级 Harness”提示，而不是误报 corrupt session/invalid seed event；或者
• 新格式写入时保持向后兼容（或读取端兼容展开旧格式）。

环境

• macOS 14 (Apple M1 Pro / arm64)
• 读取端 dsh：0.1.1-rc.2（npm latest/next 标签）
• 写入端：0.1.2-alpha.2（@alpha 标签）
• 错误来自 dsh web（Web GUI，http://127.0.0.1:3080）

验收条件

• 使用 Alpha 写入的会话，在 rc.2 下加载时不再报 SessionPersistenceCorruptionError（要么能正确展开区间读取，要么给出明确的“版本升级提示”）。
• 修复后 Session.create 能对既有、含区间 sourceEventSeqs 的日志正常加载（可参考：将 assertProvenance 前的读取路径接入 decodeSeqRanges）。

备注

• 已对受影响的用户会话做了数据级修复：把区间 [[start,end]] 展开回扁平 [start..end] 数组，从而在 rc.2 与 Alpha 两种读取端下都能加载。
• 该问题仅在“Alpha 写盘、rc.2 读盘”混合版本时出现；同一版本内部读写是自洽的。

[xiaoshenming]

这不是 seq gap，是 Alpha 把 sourceEventSeqs 写成区间 [[start,end]]，rc.2 只认扁平整数，于是 assertProvenance 把整份会话判成 corrupt。

dsh-session-surgeon 不会把区间展开成旧格式（那是改语义 / 伪迁移）。inspect 若报 foreign-version 或校验失败会 refuse，避免越修越坏。

能做的：

• 用写这段日志的同一条线打开（@alpha / 0.1.2-alpha.2），不要用 npm latest（仍是 rc.2）去读 Alpha 写的文件。
• 需要回 rc.2 就开新会话，不要指望把 Alpha 文件「修」回旧读取器。

根因是磁盘格式 bump 没有迁移路径（#4910），得官方给明确的 version refuse，而不是误报 corrupt。

[argszero]

源码侧确认（本地 0.1.2-alpha.1 = cd5ef81；#3048 已在内，alpha.2 只是延续），并补一个你们都没点到的关键事实——这不是"预期中的格式破坏"，而是版本守卫被静默绕过。

机制确认（与 OP 描述一致）：

• 写端：encodeProvenanceForStorage → encodeSeqRanges（session-persistence-jsonl/src/format.ts:236-238；实现 core/session/src/seq-ranges.ts:15-33）——连续 run ≥3 个 seq 才压成 [start,end]，94 个连续 chunk 变 [[1331,1424]] 正是这个形状；<3 的保持扁平，所以小输出不触发。
• 读端：expandProvenanceFromStorage → decodeSeqRanges（format.ts:247-256 + seq-ranges.ts:34+）能无损展开；rc.2 没有这层，assertProvenance 见到非整数直接判损坏。

关键事实：格式版本守卫存在，但 #3048 没有 bump 版本号，导致守卫失效：

• format.ts:271-283 的 refuseForeignFormatVersion 是专门为这个场景设计的——注释原文："a future format ... its user must see 'upgrade the harness', never 'corrupt session log'"。
• 但该守卫只在 typeof version === 'number' && version !== SESSION_FORMAT_VERSION 时触发；而 SESSION_FORMAT_VERSION 仍是 0（core/session/src/types.ts:56），范围压缩随 [bug] str_replace_editor: insert writes LF line endings into a CRLF file (mixed EOL) #3048（df76bc695b, "reduce persistence storage size"）落地时没有同步 bump → 新旧两侧都写/读 v0 → 守卫直接放行 → rc.2 在 assertProvenance 里把区间判成损坏。
• 也就是说：上游设计意图是旧读端遇到新格式时明确报"请升级"，而不是报 corruption；这个意图被"改了盘格式但没动版本号"破坏了。这是守卫缺口（与 [Bug report] One persisted session with an unsupported event (demo/hello) can abort global reconciliation and make session search report storage unavailable #4811/session-persistence writes a turn/end event its own validator rejects (turn: 0 vs `turn < 1`), and one bad session kills search for the whole store #5059 的判别缺口同型），不是预期的兼容性破坏。

放大因素（这才是用户能踩到的原因）：npm dist-tag 冻结。实测 npm view @deepseek-ai/dsh dist-tags：latest: 0.1.1-rc.2、alpha: 0.1.2-alpha.2——npm i -g @deepseek-ai/dsh 装的是比 alpha 更旧的 rc.2。用户试用 alpha.2（--tag alpha）后重装 latest = 静默降级，正好撞上"旧读端读新格式"。dist-tag 冻结此前已三报（#2763/#3461/#4434，根因 scripts/release/publish.ts 的 prerelease 永不取 latest），这是它造成的又一个用户可见后果——把降级路径变成日常操作。

修复 seam：

1. 写端（根修）：所有改变盘格式的改动必须同步 bump SESSION_FORMAT_VERSION——[bug] str_replace_editor: insert writes LF line endings into a CRLF file (mixed EOL) #3048 该 0→1。bump 后旧读端按设计抛 SessionFormatUnsupportedError（"upgrade the harness"），不再误报 corruption；
2. 读端纵深：assertProvenance 可把「sourceEventSeqs 出现 [start,end] 数组项」识别为"较新格式写入"，报格式不匹配而非损坏（判别成本极低）；
3. dist-tag：发布流程推进 latest + gate 校验 latest==newest（e3b9a5d1 家族三层修复），此路径自然消失。

另：dsh-session-surgeon 修复工具（xiaoshenming 帖）的方向是对的——这不是 seq gap，是格式形状差异；但更彻底的解法是版本号，否则每个新形状都会再撞一次。

[xiaoyuyu6420]

你现在的处境概括起来就是：升级一时爽，老数据读不了。这类"新版本写、旧版本读"的格式失配，官方修复要等下一版，等的过程里你既不能干净回退、历史又全瞎——最难受的位置。

这种事的正确姿势是让它在升级前就被拦住：dsh-backup 会在 dsh 版本变化时自动打一份 dsh-pre-upgrade- 快照，升级后不对劲，/backup restore 一句回到升级前的样子：

dsh plugin --profile web add @xiaoyuyu6420/dsh-backup   # 装完重启 dsh web
/backup                                                   # 手动备份
/backup restore latest --dry-run                          # 升级翻车后先预览再还原

你这批会话已经被 alpha 写过，现在能做的两步：① 先别动这批日志，等官方出修复或按楼上工具迁移；② 从现在起 /backup auto 12 定时备份，养成"升级=有退路再上"的习惯。备份要求 DSH 0.1.1-rc.2 或兼容版本（安装时会校验 peer）。

[xiaoshenming]

同意 @argszero：这是格式 bump 没改 SESSION_FORMAT_VERSION，守卫被静默绕过，旧读端才把区间误报成 corrupt。

surgeon 仍然不会把 [[start,end]] 展开成扁平整数（那是伪迁移）。main 现在会把这种文件标成 newer-format-ranges 并 refuse repair/compact，提示用写这段日志的同一版本打开，而不是当 seq gap 去裁。

备份插件能挡升级翻车，修不了已经用 Alpha 写过、又被 rc.2 拒读的那份文件——那份请继续用 alpha 打开，或等官方 bump version / 读端判别。