[Bug] session_search 永久 30s 超时：:memory: FTS 索引 + 单事务对账 + 工具超时中止，大语料必然死锁

[eddiedon]

English TL;DR

In my deployment, the session_search tool comes from the opt-in experimental bundle @deepseek-ai/dsh-experimental-session-search (enabled via the plugin manager — not part of any shipped template, see the correction note at the bottom), backed by @deepseek-ai/dsh-session-query-sqlite configured with path: ':memory:' and openAt: first-search. Before every search, the backend reconciles the entire persisted corpus into the in-memory FTS5 index and commits in a single transaction at the end, while the tool enforces a 30 s budget (searchTimeoutMs, default 3e4) whose abort signal propagates into the backend (SESSION_QUERY_ABORTED), rolling that transaction back. Once the session corpus grows past what one reconcile can process within 30 s, every search starts from an empty in-memory index, times out, rolls back, and makes zero progress — a permanent, deterministic timeout loop. Restarts cannot help (:memory:), and err.log stays clean because the abort is a typed, handled error, not a crash.

环境 / Environment

• dsh 0.2.1-alpha.2，profile web，Windows 11 x64，Node v24.18.0
• 使用场景：web GUI 日常使用；定时任务（每晚的会话沉淀）依赖 session_search 扫描当日会话

现象 / Symptoms

• 10-13 起所有 session_search 调用一律 30 秒整超时：tool call timed out after 30000ms，与查询词、时段无关
• 同后端的 session_event_search 在大会话上同样超时
• 重启守护进程无效；err.log 保持 0 字节（策略性中止，非崩溃）
• 语料规模：~/.dsh/sessions 下 9 个工作区目录、约 459 个会话 zstd 文件、约 190 MB 压缩（最大的单一工作区 379 会话 / 158 MB，其中 104 个是近 7 天新增）

排查证据 / Evidence (0.2.1-alpha.2)

1. 组合配置 ~/.dsh/profiles/web/cordis.yml（boot 后实际生效）：

   • L103-107 基础挂载：dsh-session-query-sqlite，path: ':memory:'，openAt: never

   • L1412-1420 工具实际使用的 optional-session-search 组（isolate: { sessionQuery: true }）：

     - id: optional-session-query-sqlite
       name: '@deepseek-ai/dsh-session-query-sqlite'
       config:
         path: ':memory:'
         openAt: first-search
     - id: optional-tool-session-query
       name: '@deepseek-ai/dsh-tool-session-query'

   该组内容来自 @deepseek-ai/dsh-experimental-session-search/cordis.patch.yml。注意：这是一个 shipped 模板默认不含的可选 bundle（base/web-app 的 shipped 挂载均为 openAt: never，搜索禁用），本机出现这组配置是因为我在插件管理器中启用了它——原报告此处定性有误，已在文末「更正」一节说明。

2. 全盘 ~/.dsh 下无任何 *.db 文件，佐证索引从未落盘（:memory: 的直接后果）。

3. 工具超时默认 30000ms：dsh-tool-session-query/lib/index.js 中 searchTimeoutMs: z.number()...default(DEFAULT_SEARCH_TIMEOUT_MS)、const searchTimeoutMs = config.searchTimeoutMs ?? 3e4；执行时把 exec.signal 传入 searchSessions(..., { signal })。

4. 后端中止与事务路径：dsh-session-query-sqlite/lib/index.js 中对账以 BEGIN IMMEDIATE 开单事务、结束时一次性提交；isAbort(error) || signal?.aborted 时抛 SESSION_QUERY_ABORTED → 事务回滚，已建内容全部丢弃。

5. 语料规模见上 → 单次全量对账（解压 zstd + 语义抽取 + FTS5 写入）远超 30 秒。

死锁机制 / The deadlock

每次搜索的执行顺序是：先把全语料冷建进内存索引（单事务、最后提交）→ 执行查询。而工具预算只有 30 秒，超时中止信号直达后端，事务回滚。语料一旦越过"单次对账能在 30 秒内完成"的阈值，之后每次尝试都是：空索引 → 从零冷建 → 30 秒打断 → 回滚 → 下次依旧空索引。没有任何自愈路径：:memory: 让重启也帮不上忙（重启反而保证从空开始），协作式取消让进度永远无法累积。

10-13 起所有调用超时（含 10-13 / 10-14 多次定时任务内超时与一次手动复现）。至于是"语料增长越过 30 秒冷建阈值"还是"该实验 bundle 恰在此窗口内被启用、启用即坏"，两种发病路径都成立、无法定论，见文末「更正」。

修复建议 / Suggestions

用户侧临时缓解（思路验证，未实施）：patch 用户层把 optional-session-query-sqlite.path 指到真实文件 + optional-tool-session-query.searchTimeoutMs 调大（如 600000）。两处需同改——只改 path 不够，首次冷建仍会撞 30 秒预算回滚；冷建成功一次后转为增量，恢复正常。

上游可考虑的方向：

1. shipped web 档位默认索引落盘（profile storages 下的专用文件）而非 :memory:；
2. 对账按会话粒度增量提交，中止后进度可保留、下次续建；
3. 冷建/对账与调用方的工具信号解耦，避免 30 秒工具预算约束全量重建（经官方核对：仅把 openAt 配成 startup 今天做不到——startup 路径只调用 _ensureReady 打开数据库，_reconcile 仍在每次搜索调用内携带调用方 signal 执行，需要代码级解耦）；
4. 预算不足时返回类型化错误（如 SESSION_QUERY_RECONCILE_INCOMPLETE）而非裸的工具超时，便于代理与用户诊断。

附

如需更多现场数据（配置原文、目录清单、时间线、复现脚本），随时可以提供。本文所有路径以 ~/.dsh 相对形式给出，无敏感信息。

更正 / Correction（2026-10-15，据 @PerryLink 的源码级核对修订）

1. 前提更正：session_search 不在任何 shipped 模板里。web 档位只挂 @deepseek-ai/dsh-base + @deepseek-ai/dsh-web-app，两者的 session-query-sqlite 均为 openAt: never（搜索禁用）。本文引用的 :memory: + first-search 配置属于可选 bundle @deepseek-ai/dsh-experimental-session-search（OPTIONAL_BUNDLES 成员，"offered switched off by the plugin manager"），是我在插件管理器中自行启用的（本机 profile dsh.profile.bundles 可证）。原报告"这是官方默认行为、不是用户改坏的"的表述撤回：这不是官方默认问题，而是 opt-in 实验插件在大语料机器上的表现。
2. 上游建议 #3 修订：仅把 openAt 改为 startup 今天无法把对账移出 30 秒预算——startup 只保证打开数据库（_ensureReady），_reconcile 仍在每次搜索调用内携带调用方 signal 执行。真正的后台建索引需要代码级解耦。
3. 经官方核对成立的部分：单事务 + 末尾提交 + abort 回滚 + :memory: 的死锁组合；DEFAULT_SEARCH_TIMEOUT_MS = 30_000；signal 一路贯通到后端；"只改 path 不够、必须与 searchTimeoutMs 同调放大，成功提交一次后经 revision 比对转增量"的缓解路径。

[PerryLink]

机制链条你基本说对了，但有个前提是错的，而且它决定了这条报告该怎么写：shipped 的 web 档位根本不挂这个工具——你现在是有意打开了一个可选 bundle，不是撞上了官方默认配置。

先说这个前提

packages/boot/app-boot/src/profile.ts:183-185 里 web 档位只有两个 bundle：

web: { bundles: ['@deepseek-ai/dsh-base', '@deepseek-ai/dsh-web-app'] },

而 session-query-sqlite 在 shipped 的 base 和 web-app 补丁里都是 openAt: never：

• packages/bundle/base/cordis.patch.yml:157-161（:149-156 的注释写着 "Full-text session search is opt-in. openAt: never keeps ctx.sessionQuery mounted … while search calls fail with SESSION_QUERY_SEARCH_DISABLED and SQLite is never opened"）
• packages/bundle/web-app/cordis.patch.yml:27-30 同形

你引的那段 path: ':memory:' / openAt: first-search 的 YAML，确实是逐字存在的，但它在 packages/experimental/session-search/cordis.patch.yml:1-14 —— 那是可选 bundle 的内容，而 @deepseek-ai/dsh-experimental-session-search 在 profile.ts:223-224 的 OPTIONAL_BUNDLES 列表里，注释明说 "selected by no shipped template, and offered switched off by the plugin manager"。而且 dsh-tool-session-query 在任何 shipped 的 yml 里都不存在。

所以你在 ~/.dsh/profiles/web/cordis.yml 里看到这一组，说明这个可选 bundle 已经被启用了（大概率是从插件页装的）。这不是"官方默认"，报告里要这么写，否则第一个回复就是"这个默认关着"。

我顺手也核了版本：openAt: never 在 dsh-v0.2.1-alpha.2 和 dsh-v0.2.1-alpha.3 的 base 补丁上都在，OPTIONAL_BUNDLES 在 alpha.2 也含它——所以这跟你跑哪个版本无关。

你说对的部分

单事务 + 末尾提交 + abort 回滚 + :memory:，这个组合确实让超 30 秒的语料没法自愈：

• packages/session-query/session-query-sqlite/src/index.ts:454 → db.exec('BEGIN IMMEDIATE')，:469 COMMIT、:475 ROLLBACK，而 :456-468 的 persistentDeletes / persistentChanges / liveReplacements 全在这一个事务里
• :534-535 → abort 时抛 SESSION_QUERY_ABORTED，于是整批回滚，下次重新来过
• README 里那句 "Source or transaction failure commits nothing and the next search retries" 就是这个意思

超时常量也对：packages/experimental/tool-session-query/src/index.ts:25 → DEFAULT_SEARCH_TIMEOUT_MS = 30_000，:38 是配置项的 schema default；signal 一路传到后端（src/operations.ts:100）。

有一处要修正

你建议的"改成 openAt: startup 让它在后台先对账"——这个今天不成立。session-query-sqlite/src/index.ts:265 里 openAt === 'startup' 只调 _ensureReady（:369-381，只是把 DB 打开），而 _reconcile 是在每次搜索调用里带着调用方的 signal 跑的（:276-277、:304-305）。换成 startup 并不能把对账移出那 30 秒预算。

你另外那个判断是对的：只改 path 不够——首次仍然是全量冷建，照样撞 30 秒回滚，必须同时把 searchTimeoutMs 放大到能跑完一次冷建（比如 600000）。等它成功提交过一次之后，:514 的 canReuseIndexed && ... revision === entry.revision 会让后续变成增量。

上游可以提的方向

一个是把对账拆成按会话增量提交，而不是所有写操作挤在同一个 BEGIN IMMEDIATE 里（index.ts:456-468）。另一个是"对账没跑完"这种情况给一个类型化的错误，而不是让工具层以裸超时的形式收场——现在用户看到的是一句 30 秒超时，看不出到底是查询慢还是对账没做完。

边界

我核的是 origin/master = 571902028a（2026-10-14）。另外提醒一句，你写的 3e4 只是 30_000 的等值写法，源码里用的是 DEFAULT_SEARCH_TIMEOUT_MS，引用时用常量名更方便别人检索。

[eddiedon]

感谢 @PerryLink 的逐行核对，两处更正都收下了，正文已同步修订（TL;DR 与证据 1 的定性表述、上游建议 #3，文末新增「更正」一节）。

本地考证补充，供后续遇到同类现象的读者定位：

1. 启用来源确认：本机 8/29 与 9/23 两份 profile package.json 备份的 bundles 列表都没有 @deepseek-ai/dsh-experimental-session-search，当前列表里有（与 badge / ralph / session-titles / terminal / tool-worktree 等一批 experimental bundle 并列）——确认是插件管理器 opt-in 启用，不是 shipped 默认。启用窗口在 9/23 之后、10-13 故障显现之前；精确日期已不可考（experimental 包随 CLI 主包发行，启用只改 bundles 列表，不产生 pnpm 安装日志）。
2. onset 归因存疑：因此"语料增长越过 30 秒冷建阈值"与"恰在 10-13 前后启用、启用即坏"两种发病路径都成立，原报告把 onset 归因于语料增长的那句也应保留疑问。死锁机制本身不受影响。

接下来本地按确认过的缓解路径执行：path 落盘 + searchTimeoutMs 调大两处同改，首次冷建成功提交后回帖报结果。再次感谢这么细致的核对。

[dust617]

Mitigation result: persistent index + raised searchTimeoutMs breaks the permanent-timeout loop — reproduced on 0.2.1-alpha.3 (Windows)

You wrote that you would apply path → on-disk plus a raised searchTimeoutMs and report back. Same composition here, so here is a second data point.

Environment: official @deepseek-ai/dsh 0.2.1-alpha.3, Windows 11 x64, Node v24.15.0, profile web, the same opt-in optional-session-search group (isolate: { sessionQuery: true }) with path: ':memory:' / openAt: first-search and dsh-tool-session-query at its default searchTimeoutMs = 30000. Store: 257 listed sessions.

Before the change, every session_search call ended in tool call timed out after 30000ms, i.e. your deadlock.

Two configuration changes only:

1. path: ':memory:' → !!js dshHomePath('storages/session-search.sqlite')
2. searchTimeoutMs: 240000 on optional-tool-session-query

After a restart, wall times taken from the session log (tool-call event → tool-result event):

call	wall time	result
session_search("升级")	77.7 s (13:50:18.025Z → 13:51:35.722Z)	38 hits
session_search("compaction thrash guard")	39.2 s (13:51:40.314Z → 13:52:19.493Z)	9 hits

So the loop is broken: the first reconcile now runs to completion and commits, instead of being aborted and rolled back.

Three caveats worth keeping next to the mitigation:

1. A raised timeout is necessary but not sufficient for a fast repeat search. The second call still took 39 s rather than ~1 s. On a store that contains pre-v4 sessions, every historical revision churns on unrelated activity, so reconcile keeps re-reading them; the persistent path only prevents the rebuild from starting at zero after each restart. I pinned the mechanism in a comment on [Bug] Session indexing still fails on 0.2.1-alpha.2: historical revision churn + isolated in-memory Agent index #8783 (historicalCorpusRevision in dsh-session-persistence-jsonl). The ~1 s result reported in [Bug] Session indexing still fails on 0.2.1-alpha.2: historical revision churn + isolated in-memory Agent index #8783 appears to require the v4 migration, not the persistent index alone.
2. On this store there was a third, independent blocker. 21 sessions with an unsupported subagent/descriptor version plus 2 sessions with a sequence gap made every search fail with SESSION_QUERY_PERSISTENCE_FAILED; a raised timeout does not help there. Locally I skip typed SessionPersistenceCorruptionError / SessionFormatUnsupportedError at the cold-read boundary (see [Bug] session-query-sqlite: CJK substrings are not searchable, and one unreadable Session fails every search #9064, session-query-sqlite: one corrupt cold log fails every search, and live-session churn prevents the observation from stabilising #9743, Session search fails entirely when any session contains a released subagent/descriptor v2 event (two v0→v1 migration gates + no per-session tolerance) #6545/[Bug] session search fails on any store that ever spawned a subagent — v0→v1 migration rejects `subagent/descriptor` version 2, the only version the writer emits #7995). So reaching a working search here needed all three: persistent index, raised budget, and tolerance for unreadable members.
3. Scope — as @PerryLink noted, this is an opt-in bundle, so the mitigation belongs in the bundle's shipped patch/README rather than in core defaults.

[eddiedon]

缓解已在本机 rc.2 落地并验证，补充数据点（与 @dust617 的 alpha.3 结果互为印证）：

配置（用户层 cordis.patch.yml，按 id 覆盖 optional-session-search 组内两个子条目；注意该文件补丁语义是 config 整块替换、不深合并，openAt: first-search 需原样重申）：

- id: optional-session-query-sqlite
  name: '@deepseek-ai/dsh-session-query-sqlite'
  config:
    path: !!js dshHomePath('storages/session-search.sqlite')
    openAt: first-search
- id: optional-tool-session-query
  name: '@deepseek-ai/dsh-tool-session-query'
  config:
    searchTimeoutMs: 600000

验证（0.2.1-rc.2，459 会话 / 约 190MB zstd / Windows 11 x64 / Node v24.18.0，含大量 pre-v4 老格式会话）：

1. 无需重启：rc.2 的用户层补丁文件在常驻进程上热重载生效——补丁写入时守护进程已运行近一小时，下一次 session_search 即按新配置执行。对其他用户应该是个有用的信息。
2. 冷建约 70 秒完成并落盘：storages/session-search.sqlite 178MB + WAL，文件创建 10:56:30 → 写入稳定 10:57:40（本地时间），按事件时间戳口径首次调用约 75 秒返回，11 条命中。
3. 第二次增量调用实测 91.0 秒（tool/call 03:00:40.705Z → tool/result 03:02:11.698Z），25 条命中，含 2026-08 的 pre-v4 会话。比 @dust617 的 39s 更慢，方向上与其 historicalCorpusRevision 老会话每次重对账的观察一致（本机 pre-v4 占比更高）。结论：死锁解除、功能可用，但在老会话 v4 迁移/归档之前，每次调用仍是分钟级。
4. 本库未复现 @dust617 的第三类阻断（21 个不支持版本会话导致 SESSION_QUERY_PERSISTENCE_FAILED）：459 个跨版本会话全部对账通过。毒会话问题是否存在似乎与语料构成有关，遇到同症状的用户值得先按会话格式排查。

rc.2 现状：dsh-experimental-session-search/cordis.patch.yml（仍 :memory: + first-search）、DEFAULT_SEARCH_TIMEOUT_MS = 3e4、单事务对账路径均与 alpha.2 逐点一致——本帖描述的死锁在 rc.2 默认配置下原样存在。如官方愿意收敛，把这两行配置落进 bundle 补丁默认值或 README 即可，无需代码改动；另外 rc.2 新增的 launcherSessionQueryPath boot 钩子（launcher 向进程注入派生索引路径）看起来正是为这类持久化部署预留的，尚未接入该可选组。

[eddiedon]

后续数据点：持久化索引 + 放宽 searchTimeoutMs 之后，rc.2 上每次调用的稳态成本仍是分钟级（冷建约 70s，增量 91.0s，见上条评论）。读了 dsh-session-persistence-jsonl 的 README 之后，我认为这不会随使用自愈，而是三件事的叠加：

1. 对历史（pre-v4）会话，"a read open decodes and migrates the source once, validates the current logical result, and returns it without publishing a successor"；只有 write open 才发布 v4 successor（README L87）。
2. session-search 后端的对账是纯读路径——所以内存中已迁移的准备随 corpus fingerprint churn 失效后，每次搜索都对全部历史会话重做解码+迁移（README L93："Read-only access never publishes an upgrade, so cold processes and evicted preparations repeat that work"）。
3. 历史修订的 corpus fingerprint 覆盖整个持久化根，"unrelated changes conservatively invalidate historical revisions"（L87）——任何新会话的任何写入都会让下一次搜索重新付全额成本。

本机量化：459 个会话中 196 个是 pre-v4（147 个在主工作区，最早到 2026-08），增量搜索稳定约 90s，且随历史会话累积线性变贵。

因此"每次都慢"的根治在上游，两个不改变默认行为的收敛方向：

• search 对账对历史会话改用 write-open 语义发布 successor（每个会话的迁移成本只付一次，之后走 "Current V4 body reads and revisions avoid the historical corpus scan" 快路径）；
• 或提供一次性 dsh sessions migrate 命令（批量 write-open 历史会话，走既有 generation 发布管线——README L107 已说明该机制防覆盖且源文件字节不动，缺的只是用户可及的触发面）。

在官方收敛之前，本机的缓解（持久化索引 + 大超时）至少把"永久死锁"降级为"每次分钟级"，晚间批处理场景可用；交互式高频搜索仍不实用。

[PerryLink]

这份数据点很有用，尤其是「无需重启」和「增量 91s 反而比 dust617 的 39s 更慢」这两条 —— 后者正好把「慢」的原因从「配置没调对」推到「pre-v4 占比」。我把你引的三处 README 逐条对了一遍，全部成立，另外补两个你没提的锚点。

README 原文（packages/session/session-persistence-jsonl/README.md @ rc.2）

• :87 — "For historical input, a read open decodes and migrates the source once, validates the current logical result, and returns it without publishing a successor"，以及 "Only a write open publishes the prepared successor"。
• :93 — "Read-only access never publishes an upgrade, so cold processes and evicted preparations repeat that work. Current V4 body reads and revisions avoid the historical corpus scan."
• :87 同段 — "historical revisions also fingerprint the selected files across the persistence root, so child changes invalidate cached logical events. Fingerprinting reads filesystem metadata only; unrelated changes conservatively invalidate historical revisions."
• :107 — "Only a write open publishes the prepared successor."

所以你归纳的三件事（只读不发布 successor / 对账是纯读 / fingerprint 覆盖整个持久化根）是逐字有据的，不是推断。

另外两个支持你判断的锚点

• :85 说明只读准备会把 formatStatus 停在历史版本，发布 successor 之后才变 current —— 也就是说「不发布」在状态上是可见的，你的 196 个 pre-v4 会话应该都能在 list() 的 formatStatus 里看到，这比数文件更快，也更容易在报告里复现。
• :107 还有一句 "a bounded revision-keyed memo lets an immediate observe-to-resume handoff reuse that parse" —— 那个 memo 是为「观测后立即恢复」的交接设计的，不是给反复对账用的缓存。这解释了你看到的「内存里已迁移的准备随 fingerprint churn 失效」不是 bug，是设计边界。

你提的两个收敛方向，我的取舍

方向一（对账改走 write-open 发布 successor）确实能一次性消掉重复成本，但代价要说清楚：对账是只读操作，一旦它会写盘，任何一次搜索都可能对用户的会话目录产生 +1 个 successor 文件。README :87 承诺 "The source remains byte-identical"，所以源文件不动；仍然会多出文件，而且失败路径要在只读调用里处理写失败。这不是不能做，但它是语义变更，得单独讨论，不能当成性能补丁。

方向二（dsh sessions migrate 一次性批量 write-open）我更赞成，而且成本更低：它把「什么时候重付」变成用户显式决定的事，只读路径完全不变。你说的「缺的只是用户可及的触发面」也准确 —— 发布管线本身是现成的（:107 说 write open 走 prepare → 临时文件 → Worker 校验 → 复核 revision → 不覆盖发布）。

关于 launcherSessionQueryPath

我核了，rc.2 里确实有：packages/session-query/session-query-sqlite/src/index.ts 里读这个 boot 注入的派生索引路径（另有 scripts/gen-cordis-catalog.ts 引用）。所以你说的「为持久化部署预留、尚未接入该可选组」是成立的。不过它是给 sqlite 索引文件放位置的，不解决「pre-v4 会话每次重解码」—— 两者可以叠加，但别指望它替代迁移。

最后提醒一句：你现在的缓解（持久化 + 600s 超时）把「永久死锁」降成「分钟级」，但如果 corpus fingerprint 是全局失效的，那么任何新会话的任何写入都会让下一次搜索重付全额 —— 这意味着一台白天在用的机器上，这个成本不是每小时一次，而是接近每次。你报告里那句「随历史会话累积线性变贵」可以再准确一点：它首先是被写入频率驱动的。

[eddiedon]

感谢逐条核对与两个补充锚点，formatStatus 这个可见状态特别有用——本机已经用它复核过（按目录内是否存在已发布的 session.v4.jsonl.zstd successor 计数，与 formatStatus 口径一致）：459 个会话中 196 个仍停在历史版本，与你对方向一的语义顾虑和方向二的取舍一起，作为本帖的最终快照。

写入频率这一点接受修正：本机是白天高频使用的机器，"每次搜索都重付全额"的描述比"线性变贵"更准确——昨天两次调用间隔约三分钟，期间有新会话写入，91s 的增量成本与该模型吻合。

方向一收回，同意它不是性能补丁而是语义变更；方向二（dsh sessions migrate）等待官方落地，落地前本机维持现有缓解（持久化索引 + 600s 预算），晚间批处理场景够用。

[eddiedon]

按方向二的精神本地先跑通了：写了一个独立脚本直接组合 @deepseek-ai/dsh-session-persistence-jsonl（官方持久化服务，逐个 open(id, 'write') 触发既有发布管线），对本机全部 pre-v4 会话执行了一遍——即 dsh sessions migrate 的用户态等效实现。数据：

• 196/196 发布成功，0 失败。3 个试点先做了 SHA-256 前后比对：源文件逐字节一致（含一个 v0+v3 双代目录），仅在会话目录内新增 session.v4.jsonl.zstd successor。
• 迁移后首查 31.1s（一次性把 196 份新 successor 重建进持久化 FTS 索引），稳态增量查询 3.4s（445 会话，tool/call → tool/result 事件时间戳口径：15:53:16.181Z → 15:53:19.543Z）。迁移前为 70s 冷建 / 91.0s 增量。
• 结论支持方向二的收益预期：迁移成本一次性付清后，v4-only 语料上的对账确实回到秒级，与 [Bug] Session indexing still fails on 0.2.1-alpha.2: historical revision churn + isolated in-memory Agent index #8783 报告的 ~1s 量级一致（本机 445 会话略高）。

如果官方后续落地 dsh sessions migrate，其行为预期与本脚本一致（同一条 generation 发布管线）；建议命令附带 --dry-run 列出 formatStatus: migration-required 的会话清单。