Title: [Bug] Single corrupted session.jsonl.zstd causes full DoS — no graceful degradation

[flyfox326]

Title: [Bug] Single corrupted session.jsonl.zstd causes full DoS — no graceful degradation
Body:

Bug Summary

When any single session.jsonl.zstd file in ~/.dsh/sessions/ is corrupted, dsh web fails to start entirely with no fallback or graceful degradation.

Related to #2649 (force-kill → corrupt session), but this issue focuses on the missing fault tolerance: one bad session should not kill the entire app.

Error

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

Stack: assertZstdHeaderFrame → readFirstZstdLine → listArtifacts → list → [cordis.init]

Root Cause

1. On startup, workspace plugin iterates ALL session directories under $DSH_HOME/sessions/
2. Each session.jsonl.zstd is decompressed and its first line must be {"type":"session","version":0,...}
3. If ANY file fails this check, the entire boot aborts — no skip/catch mechanism

Two corruption patterns observed in the wild:

• Truncated file: Zstd decompression fails entirely (e.g., 319-byte file from crash)
• Missing header line: File decompresses fine but first line is {"type":"assistant/chunk",...} instead of {"type":"session",...} — header was overwritten/truncated while data remains (e.g., 99KB file)

Security Impact: Trivial DoS

• Session files reside in ~/.dsh/sessions/ with user-level write permissions
• Any process with user write access can corrupt a single .zstd file to make DSH permanently unbootable
• No privilege escalation needed — writing a few bytes to one file = complete application failure
• User gets no recovery guidance, just a cryptic stack trace

Steps to Reproduce

1. Locate any session dir under ~/.dsh/sessions/
2. Overwrite session.jsonl.zstd with arbitrary bytes, or truncate it
3. Run dsh web
4. Process exits with error, port 3080 never listens

Suggested Fix

In assertZstdHeaderFrame / readFirstZstdLine / listArtifacts:

• Catch decompression or header validation errors per-session
• Warn (log) the corrupted session ID instead of throwing
• Skip the corrupted session and continue boot normally

This is how browsers handle corrupted localStorage entries: warn + skip + continue.

Environment

• DSH version: 0.1.0-rc.6
• OS: Windows 11
• Node.js: v24.18.1

[argszero]

Verified against rc.7 (99f6f02fec) — the DoS is real, the stack is accurate, and there is still no per-artifact catch on the list path. One nuance in your root-cause analysis worth correcting (it changes where the fix goes), then the family context.

1. Confirmed at source — no fault tolerance on the list path.
listArtifacts (packages/session/session-persistence-jsonl/src/index.ts:472-509) iterates every session dir and calls readFirstZstdLine (:492) with no try/catch. The throw sites:

• :762 — corrupt Zstandard session log: header frame failed validation (decompression failure, your truncated-file pattern);
• assertZstdHeaderFrame :49 — first frame is not exactly one header line (your :47-51: empty plaintext or a first frame whose newline isn't exactly at the end — the multi-line/zero-line first-frame shapes).

Both propagate up through list() → workspace plugin entry → [cordis.init] aborts the whole boot. Exactly your stack.

2. Correction: your "missing header line" pattern is actually skipped, not fatal — the DoS comes from the frame-shape throws.
parseHeaderMeta(first) (:496-497) returns undefined for a non-session first line and the loop continues. So a clean, single-line {"type":"assistant/chunk",...} first frame is tolerated (skipped artifact), not a boot-killer. The two fatal patterns are:

• Truncated file → the zstd frame is incomplete → decompression throws at :762 (your 319-byte case, and the [Bug] rc.6: force-kill during an active turn replays stale deltas → "corrupt session log: seq gap in committed region" (expected 600, got 598) with no supported recovery #2649 force-kill connection — an unclean exit can truncate mid-frame).
• First frame decodes to zero lines or multiple lines → assertZstdHeaderFrame throws (your "header overwritten while 99KB of data remains" case: the overwrite clobbered the frame boundary, so the first decodable frame is a fragment, not exactly one line).

This matters for the fix: guarding parseHeaderMeta is already done; the gap is exclusively the decode/validate throws in readFirstZstdLine. That's where the per-artifact catch belongs.

3. Your fix design is correct, with two additions.

• Catch + warn + skip per artifact in listArtifacts (around :492), naming the session id — agreed, this is the "warn + skip + continue" model and it matches how the family's fix directions have converged.
• Add quarantine: rename the corrupt artifact aside (e.g. session.jsonl.zstd.corrupt-<ts>) rather than just skipping. Without it, every subsequent boot re-decodes the same corrupt file before skipping — and the session stays invisible with no recovery path. Quarantine gives the user a named file to hand to dsh-doctor (moonquake2004's tool already has S6/S7/S8 offline checks for this family).
• Keep the throw for the selected session: the same assertZstdHeaderFrame/readFirstZstdLine is used when the user actually opens a specific session (via readFirstZstdLine → open path). There, failing loud with a clear "corrupt session — use dsh-doctor or quarantine" message is correct; only the enumeration path should degrade gracefully.

4. Security framing is valid and worth saying loudly. Any process with user-level write access to ~/.dsh/sessions/ (which is the session owner's own user) can brick dsh web boot by corrupting one file — no privilege escalation. That's the "availability amplifier" dimension of this family, and it raises the priority of the enumeration-path fix above a pure convenience improvement. Note the same amplification exists for valid-but-huge sessions (the #1550 cold-load stall) — the list path reads only headers (good), but the decode is unframed until a full frame is read, so a large first frame still costs a full decode per artifact at list time.

5. Family context. This is the third report of the availability-amplifier branch of the session-corruption family: #1473 (malformed first frame → boot abort, same throw path, verified earlier), #1550 (large/corrupt session → cold-load stall + CLOSE_WAIT pileup), and now #2998 (trivial-DoS framing + truncated-file variant). The enumeration path is the common denominator: listArtifacts is header-only by design ("Read only headers so listing scales with session count", :490) but the header read itself is a full-frame decode with no failure isolation. A per-artifact quarantine in listArtifacts is the one change that heals all three reports at once. Solid report — the repro steps and the security framing make it actionable in one pass.

[LLM-X-Factorer]

补一组发布版 rc.7 的实际 Web 启动 A/B 结果。该复现无模型、无凭据，并只使用一次性 Harness home。

环境：macOS arm64、Node 25.8.2、@deepseek-ai/dsh@0.1.0-rc.7。

对照	结果
空 session root	Web 正常 ready，HTTP 200
同一 root 加入一个畸形 session artifact	Web 在 ready 前退出，exit code 1

注入文件不是随机字节：它包含一个语法有效的 Zstandard frame，但解压后的 plaintext 在要求“第一帧恰好只有一行 header”的位置包含两行。启动错误匹配：

first frame is not exactly one header line

这说明问题不仅存在于源码 throw path：一个 artifact 的 frame 格式错误会实际阻断发布版 Web 的全部启动。边界也需要保留——该 artifact 是测试主动构造的，不代表正常模型或工具一定会生成同样的损坏。

我赞同本帖的处理方向：枚举 session 时按 artifact 隔离失败并给出明确诊断；若要 quarantine，应先保证原文件可恢复，且用户主动打开该 session 时仍然 fail loud，不能静默删除或伪装成正常会话。