SQLite unified storage degraded to legacy-only (bili v0.1.209, node v24.21.0, win32-x64) #5462

Activity

1. ranxianglei commented on Nov 1, 2026

   

   ranxianglei

   on Nov 1, 2026

   Owner

   More actions

   (ai: qwen/qwen3.8-27b)

   本条与 #5463 是同一份诊断报告的重复提交（同一作者、同一份 diagnostics、相隔约 35 秒连发）。按「先来后到」本条 #5462 是保留线程，#5463 为后到孪生。

   完整 triage 分析（机制分层 + 中毒会话根因 H1/H2 + 止血步骤 + 处置建议）已发在 #5463：#5463 。建议由 owner 关闭 #5463、保留本条。

   🚀React with 🚀1Reacted by ranxianglei
2. ranxianglei commented on Nov 1, 2026

   

   ranxianglei

   on Nov 1, 2026

   Owner

   More actions

   🤖 Powered by ework · qwen3.8-27b

   (ai: vllm-qwen/qwen3.8-27b)

   Dedup: duplicate of #5325 (and #5361) — same version (v0.1.209), same platform (win32-x64), same signature: index database failed to open (Error: database is locked) → silent degrade to legacy-only. Both were closed by the owner as already fixed on master. I've labeled this duplicate; per our rules I don't close it myself — whether to close is yours to decide.

   What actually happened (plain language)

   Your machine runs more than one bili/dsh process sharing a single sessions dir (D:\DSH\data\billion-context-sessions\). On Windows, when a second/orphaned proxy from a previous run — or Defender/the search indexer — holds the file, SQLite reports database is locked. In v0.1.209 the code treated that as "just quietly fall back to the legacy JSON files," so unified storage switched off for the whole process with no loud signal. That is the known #5325 defect class.

   Two extra lines in your log are worth calling out honestly (they are not data loss):

   • Session session-064da3d5… has some damaged rows inside index.db (a truncated content blob + a dangling reference), so loading/importing that one session keeps failing while your other session 27880741… works fine. The ingest path is a single atomic SQLite transaction, so this isn't a live write bug — it's residual damage left behind by an interrupted/torn write under that same Windows lock contention (I can't inspect your index.db from here, but the pattern — one session persistently failing while others work, with atomic ingest — points to pre-existing row damage, not a fresh corruption). In v0.1.209 those repeated per-session failures also trip a global 3-strike breaker that then disables the entire store — a design flaw that has since been removed.
   • Your conversation data is intact. FULL mode keeps writing the JSON envelope every turn, and the failing session falls back to serving from that JSON file. Only the index (fast load path + checkpoints) is affected.

   Status on master — all three degrade paths are fixed

   • Multiple processes sharing one index.db is now a supported topology (a second writer logs info only, never blocks) — PR [PR] fix(storage): a live second writer no longer blocks startup — sharing a local-disk index.db is a supported topology (rev | fix(storage): 活着的第二写者不再阻止启动——共享一个本地盘 index.db 是受支持拓扑（撤回 #5213 的拒绝策略） #5294.
   • If index.db genuinely can't open, master now refuses to start and tells you why instead of silently degrading — [PR] [storage] Degradation Semantics Bundle: Seven accepted fixes consolidated into one branch — a single merge suffices (inc | [storage] 降级语义全家桶：七个已验收修复合成一个分支，合并一次即可（含撤回损坏库自动改名） #5213 / follow-up 5159ce9. No more silent legacy-only.
   • The global 3-strike breaker that one bad session could trip is gone — a damaged session now just serves from its JSON file with a warning and can no longer drag down the whole store.

   So the reported symptom (silent degrade to legacy-only) cannot recur on the next release.

   To recover right now on v0.1.209 (pick one)

   1. Ensure only ONE bili/dsh process owns that dir — kill any stale/orphaned proxy processes and restart the degraded one (the lock holder is usually a leftover process).
   2. Or give each instance its own dir via BILI_SESSIONS_DIR.
   3. Or, if you don't need unified storage yet, set BILI_STORAGE_UNIFIED=legacy to stop the lock attempts entirely.

   Don't hand-delete index.db unless you mean to reset — it holds checkpoint blobs; the JSON envelopes stay your recovery source either way.

   标签: bug · dsh · scope/storage · p2 · duplicate（同一 sessions 目录多进程争用 SQLite 锁导致静默降级，与 #5325/#5361 同机制；会话数据无丢失）

   结构化结论（八问）

   1. 是什么问题: 统一存储(index.db)在 Windows 上被多进程共写或被杀软/索引器占用而打开失败(database is locked)，v0.1.209 把它当「悄悄退回 legacy」处理，整个进程静默退化为 legacy-only。
   2. 什么原因导致的: 根因是同一 sessions 目录被多个 bili/dsh 进程共享 + Windows 文件锁/非干净退出；日志里 session-064da3d5 的 index 行另有残留损坏(截断 blob + 悬空引用)，是同一锁争用下撕裂写的遗留损伤——ingest 是单事务原子操作，故非写入逻辑 bug。
   3. 影响范围与严重程度: 仅本机、开了 storage.unified=full 且存在多进程/孤儿代理的场景；产品仍可用(会话从 JSON 信封正常服务，无数据丢失)，损失的是快速加载路径与 checkpoint 能力 → p2。
   4. 怎么修复的: 本 issue 不新增代码——三条退化路径均已在 master 修复：多写者=支持拓扑(info-only, [PR] fix(storage): a live second writer no longer blocks startup — sharing a local-disk index.db is a supported topology (rev | fix(storage): 活着的第二写者不再阻止启动——共享一个本地盘 index.db 是受支持拓扑（撤回 #5213 的拒绝策略） #5294)、打不开=拒绝启动并给指引([PR] [storage] Degradation Semantics Bundle: Seven accepted fixes consolidated into one branch — a single merge suffices (inc | [storage] 降级语义全家桶：七个已验收修复合成一个分支，合并一次即可（含撤回损坏库自动改名） #5213/5159ce9e5)、全局三连击熔断已移除(坏会话只回退自身 JSON)。
   5. 是否有回归问题: 本次未改代码，不涉及；master 侧「静默降级→拒绝启动」是可用性优先的有意变更，已在 [PR] feat(web): Web dropdown lists all available compression prompt packs (including built-in chat) (#5319) | feat(web): 网页下拉列出全部可用压缩提示包（含内置 chat）(#5319) #5325/[PR] fix(#5337): long-session per-turn freeze — quadratic compress screening goes linear #5361 披露旧值→新值。
   6. 是否破坏缓存: 不涉及前缀缓存；只影响本地会话持久化的读取路径。
   7. 是否改了设计方向: 本 issue 不涉及；master 已把「多进程共享一个 index.db」定为受支持拓扑，方向已定。
   8. 是否引入新配置: 不新增；现成开关 BILI_STORAGE_UNIFIED / BILI_SESSIONS_DIR 可作临时规避。

   判定: 与 #5325/#5361 同症状同机制，判为重复并已打 duplicate 标签；观测到的三处退化机制全部已被 master 修复覆盖。按规则我不执行关闭，是否关闭留给你决定；升级到含上述修复的版本后，该症状不会再出现。
3. ranxianglei

   added

   bugSomething isn't workingSomething isn't working

   dsh

   duplicateThis issue or pull request already existsThis issue or pull request already exists

   p2

   scope/storage

   on Nov 1, 2026
4. ranxianglei commented on Nov 1, 2026

   

   ranxianglei

   on Nov 1, 2026

   Owner

   More actions

   🤖 Powered by ework · qwen3.8-27b

   (ai: vllm-qwen/qwen3.8-27b)

   收到，同步一下状态方便你决策：

   • 确认是孪生：本条 SQLite unified storage degraded to legacy-only (bili v0.1.209, node v24.21.0, win32-x64) #5462（较早）与 SQLite unified storage degraded to legacy-only (bili v0.1.209, node v24.21.0, win32-x64) #5463（约 35 秒后、同作者、同一份 diagnostics）是同一份报告的重复提交；二者都与已关闭的 [PR] feat(web): Web dropdown lists all available compression prompt packs (including built-in chat) (#5319) | feat(web): 网页下拉列出全部可用压缩提示包（含内置 chat）(#5319) #5325/[PR] fix(#5337): long-session per-turn freeze — quadratic compress screening goes linear #5361 同根因——Windows 上同一 sessions 目录被多个 bili/dsh 进程共写/被杀软或索引器占用 → SQLite database is locked → v0.1.209 把它当「悄悄退回 legacy」处理而静默降级。master 已把三条退化路径全修掉（多写者=支持拓扑 [PR] fix(storage): a live second writer no longer blocks startup — sharing a local-disk index.db is a supported topology (rev | fix(storage): 活着的第二写者不再阻止启动——共享一个本地盘 index.db 是受支持拓扑（撤回 #5213 的拒绝策略） #5294、打不开=拒绝启动并给指引 [PR] [storage] Degradation Semantics Bundle: Seven accepted fixes consolidated into one branch — a single merge suffices (inc | [storage] 降级语义全家桶：七个已验收修复合成一个分支，合并一次即可（含撤回损坏库自动改名） #5213/5159ce9e5、全局三连击熔断移除）。
   • 按先来后到，本条 SQLite unified storage degraded to legacy-only (bili v0.1.209, node v24.21.0, win32-x64) #5462 应保留：它的完整独立 triage（结论 + 标签 bug·dsh·scope/storage·p2·duplicate）都已在本线程就位，保留它不丢任何分析；SQLite unified storage degraded to legacy-only (bili v0.1.209, node v24.21.0, win32-x64) #5463 那边是另一位 agent 的 triage。
   • 关键一点——agent 不关闭任何 issue（owner policy 2026-10-23）：所以「关 SQLite unified storage degraded to legacy-only (bili v0.1.209, node v24.21.0, win32-x64) #5463、留 SQLite unified storage degraded to legacy-only (bili v0.1.209, node v24.21.0, win32-x64) #5462」这个动作需要你本人点，两位 agent 都不会替你关。现在球在你这边。
   • 无需再立新 issue（同一失败域，机制已在 [PR] feat(web): Web dropdown lists all available compression prompt packs (including built-in chat) (#5319) | feat(web): 网页下拉列出全部可用压缩提示包（含内置 chat）(#5319) #5325 家族覆盖）。

   一句话：两条都是 #5325 家族的重复报告，会话数据无丢失；建议保留较早的本条 #5462、由你关闭 #5463，升级到含上述修复的版本后该症状不再复现。
5. ranxianglei commented on Nov 1, 2026

   

   ranxianglei

   on Nov 1, 2026

   Owner

   More actions

   进来升级到0.1.211以上 稍后还会发212
6. ranxianglei

   closed this as completedon Nov 1, 2026