存储/持久化：SQLite 未设 busy_timeout、JSONL 回滚截断他人字节、coordinator 死循环、write-behind 滞留

[Zn070515]

背景

存储/持久化层（默认 storage-json + JSONL，sqlite 为可选后端）存在并发与容错缺口：sqlite 连接未设 busy_timeout、JSONL 追加失败回滚可能截断他人已提交字节、coordinator 在并发 append 下可能死循环、write-behind 写失败后批事件滞留。

问题 1：[中] SQLite 未设 busy_timeout，并发写立即 SQLITE_BUSY

位置：packages/storage/storage-sqlite/src/schema.ts:67（openDatabase/configureDatabase 只设 foreign_keys、journal_mode、user_version，未设 PRAGMA busy_timeout，node:sqlite 默认 0）；同类见 session-persistence-sqlite/src/schema.ts:82、session-query-sqlite/src/schema.ts:53

现象：WAL 仍只允许单写者。两个连接并发写同一库时立即抛 SQLITE_BUSY: database is locked，不等待重试。

复现：

1. 配置 sqlite 持久化后端
2. 双开两个 pnpm dsh web 指向同一 store，同时触发写入

实际结果：后到的写直接报 database is locked，无退避重试。

建议：建库后设置合理的 PRAGMA busy_timeout（如 5000ms），或在并发冲突时重试。

问题 2：[低] JSONL 追加失败回滚会截断他人已提交字节

位置：packages/session/session-persistence-jsonl/src/index.ts:663-670（rollbackAppend 截断到写前 before 大小）

现象：追加写/sync 失败时按「打开时记录的大小」截断回滚。若期间另一进程已向同一文件追加提交，其字节被一并截掉，造成静默丢事件。

复现：双进程写同一 session 文件，在写失败瞬间观察文件尾部。

实际结果：另一进程已持久化的事件被回滚截断丢失。

建议：回滚前重新读取当前文件大小，只截断本次追加的字节。

问题 3：[低] coordinator.adopt() 可能死循环，load 挂死

位置：packages/session/session-persistence/src/coordinator.ts:1039-1043

现象：for(;;) 中 commitPrepared 因 isPreparedSourceCurrent 不匹配持续返回 undefined 则无限重读重试，该 id 的 per-id 链永不 settle，load 该 session 挂死。

复现：另一进程持续 append 同一 session 时，对它执行 load。

实际结果：load 永久挂起。

建议：为重读重试加次数/时间上限，或在上游持续推进时给出可失败路径。

问题 4：[低] write-behind 写失败后批事件滞留无定时器

位置：packages/session/session-persistence/src/write-behind.ts:145-151 + 126-129

现象：startWrite 失败把 batch 重放回 pending 并置 automaticPaused=true；flush 的 drainBarrier catch 释放 barrier 后，残留 batch 既无 timer 也无 active write，须等下一个 enqueue 才被重拾。

复现：flush 期间持久化写失败（磁盘满/Windows 文件锁）后不再产生新事件。

实际结果：该批事件延迟落盘，可能丢失于进程退出。

建议：失败后为残留 batch 挂一个重试定时器，或在 pause 期间由 flush/teardown 兜底。

环境

dsh 0.1.0-rc（源码 pnpm dsh web），deepseek-v4-flash via deepseek-official，Windows 11。