Storage crash: Cannot read properties of undefined (reading 'prepare') corrupts session logs -> SessionFormatError -> sessions silently dropped from workspace list

[huangziyuan-general]

Storage crash Cannot read properties of undefined (reading 'prepare') corrupts session logs → SessionFormatError → sessions silently dropped from workspace list

Environment

• dsh 0.1.7-rc.1 → 0.1.7-rc.2 (web profile, macOS, dsh web on port 3080)
• Session format v4 (session.v4.jsonl.zstd, multi-frame zstd)

What happened

While a turn was executing a bash tool call, the storage layer crashed:

Cannot read properties of undefined (reading 'prepare')

The turn ended in an error state before the tool result was persisted. The v4 log was then left with a tool/call event that has no matching tool/result.

On the next startup, the v4 loader rejects the whole session:

stored session "session-…" is corrupt: session "session-…": stored log is corrupt:
SessionFormatError: step/end leaves unresolved tool call call_1e9c826f55824f9d8e783885

Worse: the failed session is also deregistered from the workspace registry (~/.dsh/storages/workspace.json → tables.workspaces[].sessionIds), so even after manually repairing the log file, the session never reappears in the UI list — it only shows up via the third-party archive plugin's inventory as unreadable.

This hit 4 sessions across 2 workspaces on my machine within one evening (2026-09-28, ~22:26), all with the same fingerprint. It looks like a recurring bug, not a one-off — possibly triggered by concurrent SQLite access from a project whose tooling also uses SQLite.

Expected behavior

1. If the storage handle dies mid-turn, the harness should persist a synthetic TOOL_NOT_STARTED error result (or flush the turn cleanly) so the log stays loadable.
2. Loader-side: a single unresolved tool call should not permanently evict a session from the workspace registry. Degrade gracefully (e.g. truncate the broken tail, keep the session listed with a warning).

Recovery notes (for anyone hitting this)

The session log format itself is fine to repair manually, but there are several non-obvious invariants worth documenting: multi-frame zstd layout (frame 1 = exactly the header line), 0-based seq, message events require top-level surfaceOp:"append" + non-empty message.id, and results for calls without an independent tool/call event must use the native TOOL_NOT_STARTED repair shape. Re-compressing the whole log as a single zstd frame makes it unreadable to the loader.

Happy to provide anonymized session files if useful. Related feedback: it would help a lot if dsh shipped a dsh session doctor/repair subcommand for this.

[PerryLink]

这个报错串本周已出现第二次——请与 #8792 合并

1. 为什么我这么说

你这条的崩溃是：

Cannot read properties of undefined (reading 'prepare')

而同在 Q&A 区、同期另有一条报告（#8792：两个插件 id 相同 ⇒ 宿主崩溃）的报错串完全相同：

Cannot read properties of undefined (reading 'prepare')

⇒ 同一个属性名、同一类空引用。这很可能不是两条独立缺陷，而是同一个查表返回 undefined 的位置被两种输入触发（#8792 是重复 id；你这条是存储侧）。

建议你把 #8792 引用进来并说明触发差异（你写的是 "Storage crash"，那是与"插件冲突"不同的入口）——两条合起来才能证明"同一处脆弱点、多条触发路径"，而这正是让维护者做一次防御性修复（而不是逐点打补丁）的理由。

2. 请补三样（决定它落在哪一层）

1. 完整栈的第一帧（哪个模块/函数在读 .prepare）——这是唯一能把两条区分开或合并的证据；
2. 是否可重跑：重启后能否再次触发；若能，给出最小步骤（你标题写 "Storage crash"，把触发前的动作列出）；
3. 版本：请写版本（当前最新 0.2.1-alpha.1）。

3. 建议把它写成"坏状态不该打死宿主"这一类

同在 Q&A 区、同期已有多条同主题：#8792（重复 id ⇒ 宿主崩溃）· #8589（子 agent 脱离管理面并持续循环）· #8849（子代理结算期投影失效 ⇒ 整个进程退出）。

⇒ 共同点：一个局部坏状态升级为整体不可用。建议把它们写成同一条可验收原则：

局部失效必须被局部化——不得升级为进程退出、整体视图失败或宿主崩溃。

写成一类比四条各自修更容易被排期。

4. 关于可复现性

你这条目前只有报错串，不足以判断是必现还是偶发。⇒ 第 2 条的"能否重跑"是关键：必现 ⇒ 可直接交给维护者；偶发 ⇒ 需要保留现场（日志、当时的 profile/会话状态），否则很难推进。

一条边界

我确认的是两条报告的报错串完全相同这一事实（足以建议合并）。你这条的根因以栈的第一帧为准——我没有你的存储现场。