[BUG] 0.1.5-rc.1 会话历史永久无法加载:v0→v1 拒绝已发布的 v0 形状(permission/preset 带 origin)

[Mandarin715]

English TL;DR

@deepseek-ai/dsh-session-format-v0-to-v1 refuses a released v0 payload shape, which makes the affected sessions permanently unopenable. Some earlier 0.1.x build wrote the session's first permission/preset event as {"preset":"workspace-write","origin":"default"}, but the frozen v0 inventory declares only preset:

packages/session/session-format-v0-to-v1/src/dispositions.ts:76

'permission/preset': disposition(['preset']),

assertReleasedEventPayload() → assertReleasedV0Keys() then throws has unexpected member "origin". The migration leaves the source artifact unchanged (by design), so retrying never helps and there is no self-heal: that session's history cannot be loaded again.

Suggested one-line fix — declare the member instead of rejecting the session:

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

dispositions.ts states that every listed member is preserved by the identity edge, and origin is a member that really was released, so admitting it matches the existing contract. (Dropping it in the migration would also be fine, but that has to be an explicit decision, not a side effect of strict validation killing the whole session.)

错误信息

历史加载失败：failed to observe session "session-<id>": @deepseek-ai/dsh-session-format-v0-to-v1 refuses this format v0 Session: permission/preset 0 data has unexpected member "origin"; source v0 artifact remains unchanged (raw log: …/session.jsonl.zstd)

最小复现

不需要真实会话,直接调用迁移包自己的校验函数即可复现:

import {
  assertReleasedEventPayload,
  RELEASED_V0_EVENT_DISPOSITIONS,
} from '@deepseek-ai/dsh-session-format-v0-to-v1'

// 受影响会话里 seq=0 的那个事件(会话的第一个事件),逐字取自真实文件
assertReleasedEventPayload(
  { type: 'permission/preset', seq: 0, time: 1, data: { preset: 'workspace-write', origin: 'default' } },
  0,
)
// => SessionFormatError: permission/preset 0 data has unexpected member "origin"

// 当前写入方产出的同一事件则被接受
assertReleasedEventPayload(
  { type: 'permission/preset', seq: 0, time: 1, data: { preset: 'workspace-write' } },
  0,
)
// => ok

RELEASED_V0_EVENT_DISPOSITIONS['permission/preset']
// => { required: ['preset'], optional: [], opaque: [] }

证据:origin 是"已发布的真实数据",不是文件损坏

对一个 13.1 MB / 35,916 帧 / 46,969 事件的会话逐帧解压后统计:

• 整个会话里只有一个事件的 data 带 origin —— permission/preset,seq = 0(会话的第一个事件),值 "default";
• 同一会话另外 3 个 permission/preset 事件都是 {"preset":"…"},没有 origin;
• 逐事件对照冻结布局表:missing required = 0;唯一的 unexpected member 就是这一处;
• 扫本机全部 55 个会话,只有 2 个带这个形状 → 写入方在某个版本之后不再写 origin,而更早写下的会话永久无法加载;
• 对照:能正常加载的会话,同一事件一律是 {"preset":"workspace-write"}。

附带说明(避免误判):text-chunks / reasoning-chunks / tool-call-chunks 不在冻结表里,但它们由 codec 的 PACKED_TAGS 分支走 decodePackedRun,不会经过 assertReleasedEventPayload;健康会话同样含这些类型。把它们也丢进该校验会产生数千条假违规,分析时要注意。

影响

任何由受影响版本创建、且该事件带 origin 的 v0 会话永远打不开。迁移按设计不改动源文件,所以重试、重启、升级都不会自愈,用户侧没有任何恢复手段。这类会话可能不止一个,而且往往是最大的那几个(长期使用的会话)。

环境

• DSH 0.1.5-rc.1(@deepseek-ai/dsh-session-format-v0-to-v1 版本同为 0.1.5-rc.1)
• Windows 10.0.26200 · Node v24.15.0
• 会话为更早的 0.1.x 版本所创建(v0 格式,session.jsonl.zstd 拼接帧容器)

备注

如果需要,我可以提供一个脱敏的最小 v0 作品(header + 该事件,拼接帧容器,含 content checksum)作为测试夹具,或按你们的规范补一个 tests/ 用例。本机已用"只重写含该事件的那一帧、其余帧逐字节保留"的方式验证过:修复后 6 项断言(帧数/逐帧校验和/事件数/零违规/仅目标帧变化/违规字段消失)全部通过 —— 也就是说数据侧没有其它障碍,补声明后这些会话即可加载。

[xiaoshenming]

Confirmed with a local repro against the released converter: permission/preset … data has unexpected member "origin" is exactly the frozen-disposition refusal.

dsh-session-surgeon now reports it as v0-preset-extra-member and — when the installed runtime itself migrates v0 on load (format ≥ 1) — rewrites the event to { preset }. The effective permission is unchanged, and stripping the redundant member stays correct even after you ship the inventory fix. Verified through sessionFormatV0ToV1 (refused before, clean after); --apply writes .bak.<utc> first. Details in #6151.

[Mandarin715]

Two exact lines for the record, plus one wording correction.

The refusal. 'permission/preset': disposition(['preset']) (v0→v1 dispositions.ts:76), thrown by assertReleasedV0Keys (has unexpected member) via assertReleasedEventPayload. The value validator for that event only requires a non-empty preset, so the refusal comes from the member table, not the value.

Dropping origin is inert. No consumer reads it: dsh-client-connection client.js:2966 takes data["preset"], dsh-permission-presets (applyPermissionEvent and its invariant) touch only .preset, and every writer appends { preset }. So removal cannot change the effective permission, and it stays correct even after the inventory admits the member.

The options you cite are the runtime's own. dsh-session-persistence-jsonl lib/index.js:983-986 loads sessions with exactly { recovery: 'strict', validation: 'transformed' }, so that is the correct oracle for "will it load", not merely a reasonable one.

I repaired the same way (back up → rewrite only that frame → keep the zstd content checksum → assert frame count / per-frame decode / event count / zero violations), and both affected sessions land where you describe:

session	before	after
13.1 MB, 35,916 frames, 46,969 events	refused: permission/preset 0 data has unexpected member "origin"	46,969 events fed → 5,409 restored
2.3 MB, 6,982 frames, 8,289 events	refused: same message	8,289 events fed → 671 restored

Agreed on the frame layer, with one caution for anyone writing a checker: the frames are fine, but the header is written as a frame of its own, so both zstdDecompressSync(wholeFile) and a streaming createZstdDecompress() stop at frame 0. I hit exactly that — the check first reported 0 events, then reported OK on a file that in fact refuses. Frame ranges have to be located structurally first, and a checker should treat frames > 1 && rows <= 1 as inconclusive rather than as a pass.

Wording note, because it sets expectations: on load the runtime does not rewrite the event to { preset }. permission/preset appears in the v0→v1 package only in the disposition table and the value validator, with no upgrade transform — the source artifact is left unchanged and the load aborts, so there is no self-heal on restart.