[Bug] 会话搜索必然失败：稳定性观测在存在活跃写入时不可能达成

[Will-Grindelwald]

概要

侧边栏搜索会话时永远转圈，约 50–130 秒后返回：

session search failed: SessionQueryError:
session-search persistence observation did not stabilize after one retry

这不是偶发失败，而是确定性失败：只要有任何会话正在被写入（即应用正在使用中），搜索就必然失败。
索引因此永远无法建立，形成自举死锁。

涉及两个独立缺陷，共同作用：

#	缺陷	位置	后果
1	稳定性闸门要求 stat 派生 revision 逐字节不变	session-query-sqlite	硬失败（转圈的直接原因）
2	全语料哈希被折进每个 legacy 会话的 revision	session-persistence-jsonl	单次写入使 142/164 个 revision 翻转；搜索退化为 O(语料)，并使缺陷 1 必然触发

---

环境

• DSH Desktop 0.1.7-rc.2（bundled runtime hostProtocolVersion 4），macOS 27.0 (26A428) arm64
• @deepseek-ai/dsh-session-query-sqlite 0.1.7-rc.2
• @deepseek-ai/dsh-session-persistence-jsonl 0.1.7-rc.2
• @deepseek-ai/dsh-session 0.1.7-rc.2
• 语料：164 个会话目录，231 MiB。格式分布：legacy v3-only 141 个，v3+v4 共存 6 个，v4-only 17 个
• 配置（cordis.patch.yml）：

- id: session-query-sqlite
  name: "@deepseek-ai/dsh-session-query-sqlite"
  config:
    path: ~/.dsh/storages/session-search.db
    openAt: first-search

已排除的因素：索引库结构正常（application_id 1146308689、schema v8 可正常打开）；同链路上的 session/list 正常返回（status=200 elapsed=163ms bytes=154956，147 ms 量级）——它不经过 _observeStable。所以不是权限、文件损坏或 DB 打不开。

---

缺陷 1：稳定性闸门要求 revision 不变（硬失败）

packages/session-query/session-query-sqlite/src/index.ts

// L86
const STABLE_OBSERVATION_ATTEMPTS = 2

// L495 _observeStable；循环起于 L499
for (let attempt = 0; attempt < STABLE_OBSERVATION_ATTEMPTS; attempt += 1) {
  const before = await persistence.list(listOptions)        // L510 第一次快照
  persisted = materializePersistenceSnapshots(before)       // L512
  for (const entry of persisted.values()) {
    if (canReuseIndexed && indexed.get(entry.header.id)?.revision === entry.revision) continue  // L514
    if (initiallyLive.has(entry.header.id) || ...) continue      // L520 跳过被 live 覆盖的会话
    const loaded = await readColdSessionLog(persistence, entry.header.id, signal)   // L522 冷读
    ...
  }
  const afterSnapshots = await persistence.list(listOptions)  // L528 第二次快照
  const after = materializePersistenceSnapshots(afterSnapshots)  // L530
  if (!samePersistenceSnapshots(persisted, after)) continue    // L531 ← 永远命中
  if (this._persistenceBinding !== persistenceBinding) continue  // L532
}
throw new SessionQueryError(                                   // L558-561
  'session-search persistence observation did not stabilize after one retry',  // L559
  'SESSION_QUERY_PERSISTENCE_FAILED',
)

// L911-925
function samePersistenceSnapshots(before, after): boolean {
  if (before.size !== after.size) return false
  for (const [id, first] of before) {
    const second = after.get(id)
    if (
      second === undefined
      || first.revision !== second.revision     // ← L920
      || !sameHeader(first.header, second.header)
    ) return false
  }
  return true
}

而 revision 是 stat 派生的（session-persistence-jsonl/src/index.ts:184-192）：

function fileRevision(identity: JsonlPhysicalIdentity): PersistenceRevision {
  return SessionPersistenceRevision([
    identity.dev, identity.ino, identity.size, identity.mtimeNs, identity.ctimeNs,
  ].join(':'))
}

即要求两次 list() 之间，全语料没有任何文件的 size/mtime/ctime 变化。
DSH 在对话进行中会持续 append 会话日志（实测 100 秒内 20 次写入，间隔 2–5 秒）。
一旦任何会话被写入，samePersistenceSnapshots 返回 false → continue → 两次尝试耗尽 → 抛错。

自举死锁

搜索 → 索引为空/过期 → 冷读全语料（窗口长达 50+ 秒）
     → 期间活跃会话必然 append → revision 翻转 → continue
     → 2 次尝试耗尽 → throw → 整个 reconcile 事务 ROLLBACK，不提交任何内容（L454 `BEGIN IMMEDIATE` … L469 `COMMIT`，catch 于 L475 `ROLLBACK` → 抛 `SESSION_QUERY_INDEX_FAILED`）
     → 下次搜索仍需冷读全语料 → 回到第一行

实测索引库状态印证（~/.dsh/storages/session-search.db，persisted_sessions 149 行 / persisted_docs 222,135 行 / global_generation 5）：

• 149 行中 141 行是 legacy-only 会话（其余 8 行对应有 v4 artifact 的会话）——即库里绝大多数是"语料哈希折进 revision"的那批，每次写入全部失效。
• 最近 30 分钟内被写入的 5 个会话，索引状态全部不合格：

  NO ROW   b4e4169e-bacd-48f5-9f4b-60ed116bb063
  NO ROW   7db5409e-fbe6-473c-accb-49721c7ba637
  NO ROW   099888f2-0b87-4bbf-bf0b-6b5c5336db6f
  STALE    1e307ccd-68ea-4ecc-9204-ff639976bac2  (index=…:3385114  disk=…:3825196)
  NO ROW   06b78abf-b4c9-4d88-8608-7ae04b9eb4e5

4 个无行、1 个 revision 已过期、0 个最新。不是部分成功，是提交从未落地。

---

缺陷 2：全语料哈希折进每个 legacy 会话的 revision

packages/session/session-persistence-jsonl/src/index.ts

// L458（list 单会话路径）/ L485（批量路径）
revision: selected.sourceVersion < SESSION_FORMAT_VERSION
  ? SessionPersistenceRevision(`${fileRevision(identity)}:${await this.historicalCorpusRevision(options?.signal)}`)
  : fileRevision(identity)

// L1038-1054
private async historicalCorpusRevision(signal?: AbortSignal): Promise<string> {
  const paths = (await this.listGenerations(signal)).map(source => source.sourcePath).sort()
  const hash = createHash('sha256')
  for (const path of paths) {                       // ← 遍历全语料每一个 generation 路径
    let revision: string
    try { revision = fileRevision(await stat(path, { bigint: true })) }
    catch (error) { if (!isENOENT(error)) throw error; revision = 'missing' }
    hash.update(JSON.stringify([path, revision]))
  }
  return hash.digest('hex')
}

结果：每个 legacy 会话的 revision 都包含了整个语料的哈希。

我直接测量了影响范围（在语料副本上向单个 v4 会话追加 64 字节，然后重新 list()）：

const before = await persistence.list()
const rev0 = new Map(before.map(e => [e.header.id, e.revision]))

appendFileSync(V4_ARTIFACT_PATH, Buffer.alloc(64, 0x20))   // 一次 64 字节写入

const after = await persistence.list()
const rev1 = new Map(after.map(e => [e.header.id, e.revision]))
let flipped = 0
for (const [id, r] of rev0) if (rev1.get(id) !== r) flipped++
console.log(before.length, flipped)

snapshots          : 164
ONE append to      : session-06b78abf (v4, 10929114 -> 10929178)
revisions flipped  : 142
  of which legacy (corpus-revision-folding): 141

一次 64 字节写入 → 142/164 个 revision 翻转。翻转的 legacy 会话，其 revision 中自身 stat 部分（dev:ino:size:mtimeNs:ctimeNs）逐字符相同，只有尾部拼接的语料哈希变了：

before: 16777231:258389808:1546946:1790415491311107486:1790415491311267319:23eb26b346f0f8d7…
after : 16777231:258389808:1546946:1790415491311107486:1790415491311267319:fa2c220a15d56056…
        └────────────── 自身 stat 部分完全相同 ──────────────┘ └──── 语料哈希（64 hex）────┘
same stat part? true

也就是说：这些会话自身一个字节都没变，仅因为语料里别的会话被写入，它们的 revision 就失效了。

两个后果：

1. 使缺陷 1 必然触发。 缺陷 1 的闸门要求"没有任何变化"，而一次写入就让 86% 的 revision 翻转，闸门不可能通过。
2. 搜索退化为 O(语料)。 冷读循环的跳过条件是 indexed.get(id)?.revision === entry.revision（L514）；legacy 会话的 revision 每次写入都变，于是每次 reconcile 都要重新冷读全部 141 个 legacy 会话（约 231 MiB）。

关于修复缺陷 1 的实测

单独修掉缺陷 1 后：搜索从"抛错"变为"成功返回 20 条结果"（红→绿），但耗时仍不可接受：

场景	耗时
冷搜索（索引为空）	74,219 ms
索引已建好、无写入	1,499 ms / 835 ms
索引已建好、持续写入中	73,018 / 126,096 / 82,348 / 89,361 ms

即：只有语料完全静止时才快。这符合缺陷 2 的预期（写入 → 141 个 legacy 会话全部失效 → 全量冷读）。

---

建议修复

缺陷 1（已实测验证，红 → 绿）

稳定性闸门的职责是"观测期间会话集合与身份没有变化"，而不是"文件字节没有变化"。
revision 的本职是判断"某个会话自上次索引后是否变化"（L514 的跳过条件），那个用法保留。把它额外当作索引提交的稳定性闸门是越权了：日志是 append-only，追加不改变身份。

 function samePersistenceSnapshots(before, after): boolean {
   if (before.size !== after.size) return false
   for (const [id, first] of before) {
     const second = after.get(id)
-    if (
-      second === undefined
-      || first.revision !== second.revision
-      || !sameHeader(first.header, second.header)
-    ) return false
+    if (second === undefined || !sameHeader(first.header, second.header)) return false
   }
   return true
 }

保留的部分：before.size !== after.size（新增/删除会话仍被发现）、sameHeader（逐个比对 id/createdAt/cwd/parentSession/isSeeded/delegationDepth/agentPreset）、以及 L532 的 _persistenceBinding 守卫与 L555 的 sameSessionIds 守卫。

放宽后如果冷读期间文件长大了，提交的是那一刻的快照、携带的 revision 偏旧 → 下次 reconcile 自然会重读。这正是增量机制原本的设计，可以自愈。

我试过一个更保守的变体——只对实际被冷读并提交的会话保留 revision 相等检查（if (first.loaded !== undefined && first.revision !== second.revision) return false）。
它仍然失败，因为被冷读的 legacy 会话同样带语料哈希。这说明缺陷 1 无法靠"收窄比较范围"绕过，必须先处理缺陷 2（或两者一起改）。

缺陷 2（需维护者决策）

historicalCorpusRevision 有明确的设计意图（注释："Historical logical events depend on the corpus, including members with unreadable headers."），所以不应简单删掉。但当前实现有两个问题：全语料 stat 逐文件哈希、且结果被折进每一个 legacy 会话的 revision。可选方向：

1. 把 revision 拆成"自身 revision"与"语料 revision"两个字段，让引擎只在自身 revision 变化时失效该会话，语料变化单独作为一个信号处理；
2. 缓存 historicalCorpusRevision 结果（例如按 list() 调用或短 TTL memoize），避免同一轮 reconcile 内重复计算；
3. 降低其粒度（例如只取 legacy 源，或使用目录级 mtime 而非全语料逐文件 stat）。

我没有实测这几个方向，供维护者判断。

---

复现

方式 A：直接调用引擎（不依赖 Desktop App）

在语料副本上（不要指向真实会话目录，因为需要制造写入）：

import { Context } from '@deepseek-ai/cordis'
import JsonlSessionPersistence from '@deepseek-ai/dsh-session-persistence-jsonl'
import SqliteSessionQueryEngine from '@deepseek-ai/dsh-session-query-sqlite'
import { readColdSessionLog } from '@deepseek-ai/dsh-session-query'
import { appendFileSync } from 'node:fs'

const ctx = new Context()
const persistence = new JsonlSessionPersistence(ctx, { root: ROOT /* 语料副本 */, compression: 'zstd' })

// 用一个真实会话冒充 "正在运行的会话"
const snap = await persistence.list()
const pick = /* 选一个较大的会话 */ snap[0]
const loaded = await readColdSessionLog(persistence, pick.header.id)
const liveObj = {
  id: pick.header.id, header: loaded.header,
  inheritedEventCount: loaded.inheritedEventCount,
  snapshotEvents: () => loaded.events,
}
ctx.provide('sessions', { list: () => [liveObj], get: id => (id === liveObj.id ? liveObj : undefined) })

// 关键：搜索进行中持续写入，模拟真实使用
const timer = setInterval(() => appendFileSync(ARTIFACT_PATH, Buffer.alloc(64, 0x20)), 250)

const engine = new SqliteSessionQueryEngine(ctx, { path: DB, openAt: 'first-search' })
try {
  console.log(await engine.searchSessions({ query: 'turn', limit: 20 }))
} catch (e) {
  console.log(e.code, e.message)   // SESSION_QUERY_PERSISTENCE_FAILED / did not stabilize after one retry
}
clearInterval(timer)

实测输出（语料 164 个会话、索引为陈旧快照）：

persistence.list() -> 163 snapshots (incl. all live dirs)
RESULT ok=false elapsed=50551 ms
  code   : SESSION_QUERY_PERSISTENCE_FAILED
  message: session-search persistence observation did not stabilize after one retry
churn appends during search: 179

对照：同一个未打补丁的模块（lib/index.js sha256 两次运行均为 dbecf833…）、同一份语料、同一个索引快照，唯一变量是搜索期间有没有写入。

搜索期间是否写入	结果	耗时
有（每 250 ms 追加一次，实测 197 次）	失败 SESSION_QUERY_PERSISTENCE_FAILED	56,191 ms
无（CHURN_MS 调至不可达，实测 0 次）	成功，返回 20 条	87,981 ms

这条对照是缺陷 1 的直接证据：代码本身能成功，写成失败的唯一原因就是"有并发写入"。
（顺带说明：即使成功也要 88 秒——这正是缺陷 2 造成的全量冷读开销。）

方式 B：通过运行中的 App

对 host RPC 发 session/search（POST /api/session/search，slash 形式方法名）：

status=200 elapsed=66094ms
result.ok = false
error = { "code": "gateway/internal",
          "message": "session search failed: SessionQueryError: session-search persistence observation did not stabilize after one retry" }

# 同一进程内对照组：
# session/list status=200 elapsed=163ms bytes=154956

一条最小的确定性单测

不依赖真实语料，直接针对判等语义：

1. before = materializePersistenceSnapshots(await persistence.list())
2. 向任意一个会话 artifact 追加 1 字节
3. after  = materializePersistenceSnapshots(await persistence.list())
4. assert samePersistenceSnapshots(before, after) === false   // 当前行为

把它改成 === true（对同一会话集合而言），就是缺陷 1 的回归测试。
另外建议加一条针对缺陷 2 的不变量测试：向任一 v4 会话追加 1 字节，不应导致任何 legacy 会话的 revision 变化（当前 141 个全部变化）。

---

补充观察（非本 bug，供参考）

• 版本错配：本机 ~/.dsh/profiles/node_modules/@deepseek-ai/* 有 240 个指向 /opt/homebrew/lib/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/... 的符号链接（含 dsh-session-query-sqlite），那份是 0.1.5-rc.3（dsh-session 报 SESSION_FORMAT_VERSION = 3），而 App 实际加载的是随包发布的 0.1.7-rc.2（v4）。同一个插件文件在两棵树里字节相同，差异在兄弟依赖解析到的 dsh-session 版本。这不影响本 bug 的复现，但排查时容易误判。
• 0.1.7-rc.2 里 _observeStable 每次尝试都对全部 live 会话重跑 observeLive（L548-553，无缓存）；这是搜索耗时中的另一项成本，与上述两个缺陷独立。

[Fantasymax]

English summary — Same failure confirmed on a different platform and a newer release: DSH Desktop 0.2.0-rc.2, Windows 11 x64, corpus 182 sessions / 110 MB (zstd). Adding two things the original post does not cover: (1) the on-disk cost of a single failed attempt (~375 MB of index DB + WAL), and (2) an operational finding — reverting the config at runtime does not stop the in-flight reconcile; only a full app restart recovers.

---

感谢原帖，根因分析（缺陷 1 / 缺陷 2）与实测耗时已经把问题讲透了。以下只补充原帖未覆盖的部分，不重复结论。

1. 复现面：换平台、换版本，仍然复现

	原帖	本次
DSH	Desktop 0.1.7-rc.2	Desktop 0.2.0-rc.2（随包 @deepseek-ai/* 均为该版本）
平台	macOS 27.0 arm64	Windows 11 x64
语料	164 个会话 / 231 MiB	182 个会话 / 110.4 MB（zstd 落盘体积）
配置	path + openAt: first-search	同上

两点结论：

• 0.2.0-rc.2 未修复，不是已在更新的版本里解决的问题。
• 与平台无关。另外注意语料体积差了一倍多（110 MB vs 231 MiB）却同样必现，说明触发条件不是单纯的字节数，而是"存在活跃写入 + 需要全量冷读"这个组合——这与原帖缺陷 2 的判断一致。

2. 一次失败尝试的磁盘开销（补充证据）

搜索无结果、放弃后，索引目录状态：

文件	大小
session-search.db	187.2 MB
session-search.db-wal	188.3 MB

两个文件的时间戳都停在放弃的那一刻，WAL 未 checkpoint；重启应用后 WAL 被并入主库，主库保持在 187.2 MB 不再回缩。

这与"ROLLBACK 不提交内容"是自洽的：一次失败的 reconcile 会把约 375 MB 写进 WAL 再回滚，页留在 freelist 里，SQLite 不会缩小文件。也就是说每次失败尝试都要付一次数百 MB 的磁盘写放大，而这个自我强化的死锁意味着会反复失败。

（同一次卡顿期间，Host 进程 RSS 观测到约 1.5 GB。这是观测值，我没有做归因，仅作参考。）

3. 操作层面：运行期撤销配置无法止损

我先加上覆盖行复现，随后把该行整段删除（同一 profile 的 cordis.patch.yml，该 profile 配置为 patchReload: live）。Host 没有恢复，仍处于卡死状态；直到整个应用进程重启才解开。

诚实标注不确定性：我无法区分当时是"同一次 reconcile 仍在跑"还是"重载后新实例又触发了一次"。但两种情况指向同一个可用性问题——用户无法自助止损，只能重启应用。

这与 #8277 / #7356 的结论一致：reconcile 期间跑在 JS 主线程上的同步工作不可中断。

4. 交叉引用：这可能是同一族问题

• #8277 — readEvent 经 snapshotLive 深拷贝整个会话日志，同步阻塞主线程，期间 Host 完全不响应 HTTP
• #7356 — 同一处，实测 91.4% CPU 在 structuredClone，单次卡顿约 8.5 分钟

加上本贴，三条都指向同一个模式：session-query 家族把 O(语料) 的同步工作放在 Host 主线程上执行。

这一点对修复优先级有影响：按原帖实测，单独修好缺陷 1 之后，索引已建好且持续写入时搜索仍需 73–126 秒。那时它不再抛错，但会变成一个持续 1–2 分钟的主线程阻塞——用户体验上仍是不可用。所以建议在修缺陷 1 / 2 的同时，一并考虑把 reconcile 移出主线程（异步或 worker），否则修完只是从"报错"变成"长时间假死"。

---

再次感谢原帖的复现脚本与修复验证，这篇补充只是把复现面和运行期行为补齐。