Failed to load history: failed to observe session

[NadjiHamid]

Failed to load history: failed to observe session "session-43613f79-e771-4f88-8931-7f9b30df6a2d": @deepseek-ai/dsh-session-format-v0-to-v1 refuses this format v0 Session: assistant/chunk 110 chunk replayState has unexpected member "kind"; source v0 artifact remains unchanged (raw log: /home//.dsh/sessions/--home--***-workspace--/session-43613f79-e771-4f88-8931-7f9b30df6a2d/session.jsonl.zstd) (gateway/internal)

[xiaoyuyu6420]

先说最重要的：这个会话文件没有坏。报错里 source v0 artifact remains unchanged 是迁移器（v0→v1）在 chunk 110 遇到一个它不认识的字段（replayState.kind）后主动拒收——fail-fast 是故意的，为的是不碰坏你的原件。影响的也只是这一个会话，其他会话照常迁移打开。

能做的三件事：

1. 这个需要上游修：迁移器对未知成员应该宽容（跳过/忽略 kind，而不是拒收整份会话）。你贴的报错已经很完整，建议在帖里补两个信息给维护者定位：当前 dsh 版本，以及这个会话大概是哪个版本时期创建的（kind 这个字段应该是某条版本线的 v0 写端加过、迁移器没跟上的）。
2. 想立刻读这个老会话：它还是完好的 v0 原件，用写它的那个旧版本就能读——npx @deepseek-ai/dsh@<旧版本号> web 起个临时实例（按会话创建时间选版本，比如 0.1.1-rc.2），把需要的内容复制出来。
3. 别手改文件绕过校验：直接去改 session.jsonl.zstd 里的内容会让 v0 原件也变脏，等上游把迁移器修宽容了反而更难救——原件保持原样是最安全的状态。

[jiangjiaqing]

I reproduced this failure against a persisted v0 Session and prepared a tested fix.

The migration recognizes the exact flat pi-ai version-1 replay state, wraps both the finish-chunk and assistant-message copies as { response, blocks }, and preserves every adapter-private response and block value. The original v0 generation remains unchanged; the persistence provider publishes the validated current successor.

External pull requests are currently disabled for this repository, so the fix is available from my fork:

• Branch: https://github.com/jiangjiaqing/deepseek-harness/tree/fix/session-v0-flat-pi-ai-replay
• Commit: jiangjiaqing@bdc13e3

Verification includes focused 100% affected-source coverage, an assembled headless v0 resume regression, migration of the reported real Session shape, Host build and pre-push typecheck, lint, and all documentation gates. The commit is cleanly based on current master and can be cherry-picked directly.

[yamingmou]

EN / English

This failure mode was flagged before it shipped. On Aug 28 we posted #4910: format v0 never had a unified contract (SESSION_FORMAT_VERSION stuck at 0, no migration path), and writers left private members in their logs — so any schema-driven one-shot migrator would trip on an unforeseen v0 variant. That is exactly what the official v0→v1 migrator is doing here on replayState.kind.

jiangjiaqing's per-shape fix is a sound stopgap — and itself evidence for the underlying point: if v0 were well-specified, shapes wouldn't need recognizing one at a time. We'd second xiaoyuyu6420's direction (tolerate unknown members), but that only rescues sessions whose variant is known; the structural fix is format governance so variants stop accumulating. #4910 documents the same class of problem on the npm side with concrete log shapes.

Authorship note: reproduced and documented by me in real-world usage; root-cause tracing and drafting assisted by AI; verification and publication by me. I have no engineering background — if any technical claim reads wrong, please call it out; I will re-verify against the toolchain and correct.

---

中文版 / ZH

这个失败模式在它上线前就被预判了。8/28 我们发 #4910：格式 v0 从来没有统一契约（SESSION_FORMAT_VERSION 停在 0、无迁移路径），写入方在日志里留下私有成员——任何"按 schema 一次性迁移"都会撞上未预见的 v0 变体。这正是官方 v0→v1 迁移器今天在 replayState.kind 上遇到的事。

jiangjiaqing 的逐形态修是有效的临时方案——同时本身就在反证核心论点：如果 v0 是良好规范的，就不需要一个形态一个形态地识别。我们赞同 xiaoyuyu6420 的方向（宽容未知成员），但那只能救活"变体已知"的会话；结构性修复是格式治理，让变体不再累积。#4910 记录了 npm 侧的同类问题及具体日志形态。

协作说明：本文由我在真实使用中复现并记录；根因与成文由 AI 协助完成，我负责校验与发布。我非工程背景，技术表述如有错误，欢迎指出——我会回去用工具链重新验证后更正。

[jiangjiaqing]

Thanks @yamingmou for taking a look and for confirming that the exact-shape migration is a sound stopgap.

I agree that the broader v0 tolerance and format-governance question is worth addressing separately. I kept this change intentionally narrow because released Session migrations in this repository are fail-fast: it recognizes only the historical flat pi-ai v1 replay state that we can identify, preserves every provider-private response and block member, validates the v2 successor, and leaves the source v0 artifact unchanged. Silently dropping unknown members would recover more files, but could also reinterpret an unrecognized durable format.

The reported real Session is recoverable with this branch, and the branch is still cleanly based on current master as of September 7, 2026. If the maintainers prefer a different ownership split—pi-ai normalization, a broader migration successor, or a separate follow-up for other released variants—I am happy to rework or split the change. I can also provide a minimized, redacted real-world fixture if that would help review.