Issue：dsh web 启动时崩溃循环——只要有一个会话文件的首个 Zstandard 帧不是"恰好一行 header"就会挂

[NattoCB]

环境

• 包：@deepseek-ai/dsh（以及 @deepseek-ai/dsh-session-persistence-jsonl、@deepseek-ai/dsh-workspace、@deepseek-ai/dsh-app-boot）—— 均为 0.1.0-rc.6
• 运行时：Node.js v22.22.2
• 系统：macOS 26.6.1（arm64）
• 服务：launchd 代理 com.deepseek.dsh.web，执行 dsh web，监听 127.0.0.1:3080

概要

dsh web 无法启动，陷入无限的"崩溃→重启"循环（launchd plist 里配了 KeepAlive）。~/.dsh/sessions 下单个损坏的会话文件就会让整个进程启动失败，导致整个 Web 服务（以及其它所有会话）都不可访问。

launchctl print 显示循环在不断加剧：

runs = 1340          (持续增长)
last exit code = 1
state = spawn scheduled

现象

每次拉起进程都以退出码 1 结束。stderr 日志（~/Library/Logs/deepseek-dsh.error.log）末尾为：

Error: dsh: plugin tree failed to load: failed to apply loader entry include (cordis:include):
  failed to apply loader entry workspace (@deepseek-ai/dsh-workspace):
  corrupt Zstandard session log: first frame is not exactly one header line
Error: corrupt Zstandard session log: first frame is not exactly one header line
    at assertZstdHeaderFrame (.../@deepseek-ai/dsh-session-persistence-jsonl/lib/index.js:742:86)
    at Proxy.readFirstZstdLine (.../@deepseek-ai/dsh-session-persistence-jsonl/lib/index.js:1307:5)
    at async Proxy.listArtifacts (.../@deepseek-ai/dsh-session-persistence-jsonl/lib/index.js:1078:49)
    at async Proxy.list (.../@deepseek-ai/dsh-session-persistence-jsonl/lib/index.js:1038:11)
    at async [cordis.init] (.../@deepseek-ai/dsh-workspace/lib/index.js:324:65)
    at async Fiber._reload (.../@deepseek-ai/cordis/lib/index.js:1355:5)
    ...
    at boot (.../@deepseek-ai/dsh-app-boot/lib/index.js:1186:9)
    at async runProfile (.../@deepseek-ai/dsh/lib/profile-boot-*.js:247:14)
    at async file://.../@deepseek-ai/dsh/lib/bin.js:133:3

根因

dsh-workspace 的 [cordis.init] 调用 sessionPersistence.list() 来枚举所有会话文件。对每个文件，listArtifacts() 读取第一个 Zstandard 帧并用 assertZstdHeaderFrame 校验。

源码位置（packages/session/session-persistence-jsonl/src/index.ts）：

// src/index.ts:47
function assertZstdHeaderFrame(plaintext: Buffer): void {
  if (plaintext.length === 0 || plaintext.indexOf(0x0A) !== plaintext.length - 1) {
    throw new Error('corrupt Zstandard session log: first frame is not exactly one header line')
  }
}

约束是：会话文件的第一帧解压后必须恰好是一行、且以 \n 结尾。 该校验在启动路径上，单文件失败即整体退出。

在出问题的那个文件里，整个会话（header 的 JSON 行加上全部事件行）被写进了单个 Zstandard 帧：

• 解压后的第一帧 = 38,936 字节
• 第一个 \n 在 byte 217，最后一个 \n 在 byte 38,935 → 多行
• 因此 plaintext.indexOf(0x0A) !== plaintext.length - 1 → 抛错

而这个异常是在插件初始化的 list() 里抛出的，未被捕获：

// src/index.ts:472 `listArtifacts()` 的逐文件循环内：
const first = this.compression === 'zstd'
  ? await this.readFirstZstdLine(path, signal)   // ← 这里抛出，无 try/catch
  : await this.readFirstLine(path, signal)

抛错点不止 assertZstdHeaderFrame 一处，readFirstZstdLine（src/index.ts:737）路径上还有：

1. scanZstdFrames（src/zstd.ts）：invalid frame magic / reserved frame-header bit / reserved block type
2. decompressZstdFrame 失败 → 包装为 header frame failed validation（src/index.ts:762）
3. assertZstdHeaderFrame 多行 → first frame is not exactly one header line（src/index.ts:765）

这三类都会沿 listArtifacts → list → [cordis.init] 一路冒泡，导致整个插件树加载失败、进程退出。由于该文件既没被跳过也没被隔离，下一次 KeepAlive 重启又撞上同一个文件，再次崩溃——无限循环。

对照：非压缩路径的 readFirstLine（src/index.ts:710）遇到"无完整首行"时返回 undefined，随后 listArtifacts 里的 if (first === undefined) continue 会安静跳过空/半写文件。损坏的 zstd 首帧走的是抛异常路径，没有同等的跳过待遇。

影响

• 严重程度：高。 一个损坏/不合规的会话文件就能拖垮整个 dsh 进程。对长期运行 / 自动化会话尤其致命——这类服务本应常驻可用。
• 产品内没有恢复路径：唯一恢复办法是手动改文件系统（隔离/改名坏文件）。

复现步骤

1. 构造一个会话文件，其首个 Zstandard 帧解压后不是"恰好一行 header"——例如某个 session.jsonl.zstd 的第一帧同时包含 header 和若干事件行，或第一帧为空 / 没有结尾换行。
2. 把它放到 ~/.dsh/sessions/<projectDir>/<sessionId>/session.jsonl.zstd。
3. 启动任意需要枚举会话的 profile（dsh web，或 TUI）。
4. 观察：进程立即退出（码 1），在带 KeepAlive 的管控下陷入无限崩溃循环。

预期行为

单个损坏的会话文件不应拖垮整个服务。持久化层应当把这个坏文件隔离，打一条 warning，然后继续加载其余会话，让 workspace 仍能启动。

建议修复

让 JsonlSessionPersistence.listArtifacts() 具备单文件容错能力：在逐文件循环内捕获单文件的校验/解码失败（assertZstdHeaderFrame、首帧解码、非法 magic），将该文件隔离（改名）并 continue，使聚合的 list() 结果只返回有效文件，同时保留对 abort 信号、重复 id、encoding mismatch 等结构性错误的正常抛出。

[zoahdev]

Confirmed at source level and implemented as a cherry-pick-ready branch - same philosophy as #1954: one corrupt artifact must never take down the whole service.

Source audit (master 47f9438)

packages/session/session-persistence-jsonl/src/index.ts - listArtifacts() calls readFirstZstdLine() per session file and lets any assertZstdHeaderFrame failure propagate. dsh-workspace's [cordis.init] calls list() during boot, so a single malformed first frame rejects the whole plugin tree and dsh web crash-loops (your launchd log shows exactly that chain).

Patch: fix/session-list-isolate-corrupt

https://github.com/zoahdev/deepseek-harness/tree/fix/session-list-isolate-corrupt

• listArtifacts now isolates per-file corruption: a log whose header frame cannot be read/decoded, or whose header identity does not match its storage path, is skipped with a loud warning while listing continues.
• Targeted reads (load) still reject for the same corrupt file - no silent data loss on the read path.
• Systemic errors stay fatal: encoding mismatch and duplicate session ids across project directories.

Verification

• tsc -b tsconfig.host.json - clean
• session-persistence-jsonl 239/239, including updated isolation expectations plus a new assertion that a good session stays reachable next to a corrupt one

Worth pairing with a doctor session-storage check (validate every storages/*.json + header frames at boot) so the corruption is reported by name instead of silently skipped - happy to add that to dsh-plugin-doctor.