SQLite unified storage degraded to legacy-only (bili v0.1.201, node v20.19.5, win32-x64)

=== billion-context diagnostics ===
generated: 2026-10-19T06:12:39.945Z
bili version: 0.1.201 (commit ff42dcc)
node: v20.19.5
platform: win32 x64
os: Windows_NT 10.0.22631
uptime: 3h 37m
--- storage ---
requested mode: shadow
effective mode: legacy
degrade reason: no SQLite engine available (node:sqlite missing, better-sqlite3 not installed) — node:sqlite needs Node.js >= 22.5; upgrade Node.js for the builtin engine (engine tarball mirrors tried in order: npm + npmmirror; set BILI_UPDATE_REGISTRY or update.registry to pin one)
engine: none
engine bootstrap: cooldown
bootstrap failure marker: at=2026-10-19T01:16:10.598Z reason="The operation was aborted due to timeout" (cooldown ~64m remaining)
BILI_STORAGE_UNIFIED: (unset)
storage.unified (config file): (unset)
BILI_STORAGE_JSON_WRITER: (unset)
storage.jsonWriter (config file): (unset)
BILI_SQLITE_AUTO_DOWNLOAD: (unset)
storage.sqliteAutoDownload (config file): (unset)
BILI_STORAGE_WAL_JOURNAL_SIZE_LIMIT_BYTES: (unset)
storage.walJournalSizeLimitBytes (config file): (unset)
BILI_ENCRYPTION_KEY set: no
sessions on disk: 0
last [storage] log lines:
2026-10-16T08:03:38.507Z [info] [v=0.1.197] [storage] unified shadow mode ENABLED (storage.unified=shadow or BILI_STORAGE_UNIFIED): every session write is double-ingested into index.db and digest-reconciled [engine: node:sqlite/builtin]
2026-10-16T08:05:24.884Z [info] [v=0.1.197] [storage] unified shadow mode ENABLED (storage.unified=shadow or BILI_STORAGE_UNIFIED): every session write is double-ingested into index.db and digest-reconciled [engine: node:sqlite/builtin]
2026-10-19T01:16:10.622Z [warn] [v=0.1.197] [storage] unified sidecar failed to open C:\Users\liuwf.local\share\billion-context\sessions/index.db (Error: [storage:node:sqlite] no SQLite engine available) — staying legacy-only; delete the file to reset the index
2026-10-19T01:25:33.228Z [warn] [v=0.1.199] [storage] unified sidecar failed to open C:\Users\liuwf.local\share\billion-context\sessions/index.db (Error: [storage:node:sqlite] no SQLite engine available) — staying legacy-only; delete the file to reset the index
2026-10-19T02:34:46.813Z [warn] [v=0.1.201] [storage] unified sidecar failed to open C:\Users\liuwf.local\share\billion-context\sessions/index.db (Error: [storage:node:sqlite] no SQLite engine available) — staying legacy-only; delete the file to reset the index
2026-10-19T06:12:36.288Z [warn] [v=0.1.201] [storage] unified sidecar failed to open C:\Users\liuwf.local\share\billion-context\sessions/index.db (Error: [storage:node:sqlite] no SQLite engine available) — staying legacy-only; delete the file to reset the index

🤖 Powered by ework · qwen3.8-27b

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

查重: 不重复 —— 与 #3338 同机制家族(引擎下载失败 → 降级 legacy-only),但本例暴露了 #3338 未覆盖的两个新面:①旧版本写下的冷却标记,会压制新版本里已经修好的重试逻辑;②用户没有任何手段在 6 小时冷却结束前强制立即重试。保持独立打开,与 #3338/#2833 关联。

标签: bug / scope/storage / p2(unified 存储功能降级但产品可用,有绕行手段)

排查结论(已按你的版本 v0.1.201 = 当前 master 代码逐条验证):

你的机器 Node 是 v20.19.5,没有 Node ≥ 22.5 才内置的 node:sqlite,也没装 better-sqlite3,bili 只能靠自下载预构建引擎(~11MB)。
关键时间线:10-19 01:16 UTC 那次失败时,运行的还是 v0.1.197(日志行 [v=0.1.197],冷却标记写入时间与它只差 24ms)——该版本的下载预算只有 10 秒、单一 registry,下 11MB 超时几乎必然,失败后设了 6 小时冷却。
这个问题(SQLite unified storage degraded to legacy-only (bili v0.1.197, node v20.19.5, win32-x64) #3338)其实已经修过:v0.1.198 起预算是 60 秒、并加了 npmmirror 兜底。你的机器确实自动升到了 0.1.199/0.1.201,但冷却标记不区分版本——新版看到旧版刚写的「刚失败」标记就跳过下载,直到 07:16 UTC。这就是诊断里 "cooldown ~64m remaining" 的来历。(旁证:标记里的 reason 没有新版会附带的 "(tried mirrors: …)" 后缀,符合 v0.1.197 单 registry 代码的特征。)
一个值得注意的线索:10-16 的日志显示 [engine: node:sqlite/builtin]——说明当时 bili 进程跑在 Node ≥ 22.5 上;现在诊断报 v20.19.5。看起来这两天内机器的默认 Node 变了(或不同启动方式选到了不同 Node)。

你现在可以做的(任选其一):

等到今天 07:16 UTC(你提 issue 后约一小时),下次启动会自动用新逻辑重试(npm + npmmirror 各 60s);
想立即重试:删掉冷却标记文件 C:\Users\liuwf\.cache\billion-context\sqlite\.bootstrap-failed.json,再重启 bili;
或者把 Node 升到 ≥ 22.5(用内置引擎,从此不用下载);
如果你不需要 unified 存储:在配置里设 "storage": {"unified": "legacy"} 显式退出(警告消失,行为不变)。

三个问题(帮我确认网络侧是否还有后续问题):

启动 agent 的 shell 里 node -v 是什么?10-16 前后换过 Node 版本吗?
10-19 01:15 UTC 前后机器能否正常访问 npmjs / npmmirror(公司代理、内网限制)?
07:16 UTC 之后是否恢复了——在 bili.log 搜 [storage] sqlite engine self-bootstrap: ok;若仍失败,请把最新几行 [storage] 贴上来。

我们这边继续推进两件不需要决策的事:①诊断输出补上冷却到期时刻和标记文件路径,让用户直接知道怎么强制重试;②把这些逃生口写进 CONFIGURATION.md。另有几项改进方案(cooldown 标记带版本、强制重试命令、按失败类型缩短冷却等)需要你拍板,细节见后续评论。

docs: sync stale bootstrap timeout comment with the #3338 60s budget …

🤖 Powered by ework · qwen3.8-27b

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

进展：不依赖决策的部分已修完 —— PR #3790（#3790 ，CI 跑中）：

诊断块现在直接显示冷却的绝对到期时间（until <ISO>，不再只有"~64m remaining"这种相对值）和标记文件的确切路径；
新增一行 force immediate retry: delete <路径> and restart —— 强制立即重试的操作入口写进诊断输出本身；
CONFIGURATION.md 中英两版在 storage.sqliteAutoDownload 条目补了 6 小时冷却、标记位置与强制重试方法。
行为变更披露：仅诊断块文本格式变化（旧行追加 , until <ISO> + 新增一行），wire API（/__bili/status、/__bili/overview）不变，无配置面变化——详见 PR 描述。本地定向测试全绿（新套件 3/3 + 相邻三套件 36/36）、typecheck 干净，全套件以 CI 为准。
顺手小修（独立标注 commit）：cli.ts 一处注释还写着旧的 ~10s 下载预算，已同步为 SQLite unified storage degraded to legacy-only (bili v0.1.197, node v20.19.5, win32-x64) #3338 的 60s。

以下 4 项需要你拍板（P1–P4）。拍板后我按批准的子集合并成一个 follow-up PR 收进本 issue（同一机制族「SQLite 引擎自下载的冷却/重试策略」，不拆片）。

八问

是什么问题：SQLite 引擎自下载的冷却重试策略有四个缺口——冷却标记不记版本（旧版本的失败会压制新版本修好的重试，本次事故正是这个）、没有正式的强制重试入口、所有失败类型一刀切等 6 小时、长驻插件宿主进程内永不重试（冷却过期了也得手动重启）。
什么原因导致的：冷却机制（彻底解决 dsh/pnpm 构建脚本门导致 build-blocked：SQLite 引擎自举（内置优先 → 运行时自下载 → 复用宿主） #2833/SQLite unified storage degraded to legacy-only (bili v0.1.197, node v20.19.5, win32-x64) #3338）设计目标单一是"防重试风暴"：一个全局 6 小时时钟，既不区分是谁（哪个版本）写入的、为什么失败（网络超时 vs 校验损坏）、被谁读（短命 CLI vs 天级插件宿主）。本次事故链 = v0.1.197 的 10s 超时写标记 → v0.1.198+ 修好了重试路径却被版本无关的标记压住 → 用户只能干等。
影响范围与严重程度（按选项）：
- P1-A（标记记版本）：影响"旧版下载失败→自动升级新版"的机器（即本 issue 形态）；现状是静默降级为 legacy-only（p2，能用但统一存储失效）；修后此类机器升级即恢复。
- P1-B（维持现状）：靠用户按诊断提示手删文件，同样 p2，且每次修复随新版本发布都会重演一次。
- P2-A（只文档化删文件）：用户要自己找到缓存目录删点文件，体验摩擦（p3）。
- P2-B（doctor --fix 加一步）：一条命令恢复（p3 → 无）。
- P3-A（维持平铺 6h）：瞬时网络故障最多让用户等 6 小时（特定条件下 p2）。
- P3-B（超时类短冷却）：同一下降到分钟级。
- P4-A（不动）：dsh/opencode/pi 等长驻宿主在启动时撞上冷却就整程 legacy，直到人工重启（p2，面=所有插件宿主用户）。
- P4-B（过期后补试一次）：自动恢复，消除该类。
怎么修复的（推荐组合 P1-A + P2-B + P3-B + P4-B）：
- P1：标记 JSON 写入 biliVersion，读取时发现版本不符即视为已过期（一个字段 + 一次比较）；
- P2：bili doctor --fix（现有的"显式请求收敛"入口，dsh 车道自动更新改全:自愈同步三本账(manifest/lockfile/副本)+ 存量漂移显式修复,自动更新后必须还能用 #3496）增加清除失败标记一步，不新增 CLI 动词；
- P3：失败分类——超时/网络不可达用短冷却（建议 15min，具名常量），校验损坏/不支持平台保持 6h；
- P4：统一存储打开时报"无引擎"且相对进程启动时冷却已过期 → 再跑一次 ensureSqliteEngine，每个冷却周期至多补试一次（防风暴上限）。
是否有回归问题（按选项）：
- P1-A：仅改变"标记版本 ≠ 当前版本"场景的行为（由压制变重试）；离线机器每次升级会多一次 ~11MB 下载尝试然后重新进入冷却——有界可接受；健康路径（无标记/缓存命中）零影响。
- P2-B：doctor --fix 语义从"账本收敛"扩为"也清 bootstrap 标记"——需在输出里披露这一步；只删一个点文件，风险低。
- P3-B：registry 持续故障时下载尝试频率从每 6h 一次变为每 15min 一次（仍远低于无冷却时的风暴水平）；常量取值需你确认。
- P4-B：在 sidecar 打开路径引入受控重试——主要风险是重试风暴/并发，用"每冷却周期至多一次"上限钉住并配单测；现有 inFlight 去重不受影响。
是否破坏缓存：四项都不触碰会话缓存/digest/watermark；P4 只重跑引擎引导本身（幂等，已有去重）。
是否改了设计方向：没有。四项都是对既有冷却机制按其原意（防重试风暴）做精细化，无架构转向。
是否引入了新的配置：四项都不新增 env/config key；P3 的时长是内部具名常量不对外暴露——若要可调需走配置面审批，另议。

选项对比表

项	选项	行为	代价/风险	建议
P1	A：标记记版本	旧版本标记不再压制新版本的重试	极小（一个字段+一次比较）	✅
P1	B：维持现状	靠手删文件（诊断已给路径）	零，但问题随每个新版本重演	兜底
P2	A：只文档化	用户自己删点文件	零	兜底
P2	B：doctor --fix 加清标记	一条命令强制重试	语义小幅扩展，需在输出披露	✅
P3	A：平铺 6h 不变	现状	零	—
P3	B：超时类短冷却（15min？）	瞬时故障分钟级恢复	registry 长期坏时尝试略增	✅（取值待你定）
P4	A：不动	插件宿主等人工重启	零	兜底
P4	B：冷却过期后补试一次	长驻宿主自动恢复	需防风暴上限（已含在方案里）	✅

一句话即可拍板（例如"都按建议来"或逐项指定）。在此之前 #3790 可以先合入——它独立成立，不依赖任何上述决策。

docs: source the #3788 cooldown text from the config-docs seed (fixes…

🤖 Powered by ework · qwen3.8-27b

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

状态更新：PR #3790 的 CI 已全部跑完，全绿（18 个检查通过、12 个按设计跳过、0 失败——含 ubuntu/windows 两个平台的全部测试分片和 docs-sync 等所有守卫）。

说明一下过程：第一轮 CI 只有一个 docs-sync 红——CONFIGURATION.md 的表格行是由 tools/gen-config-docs.mjs 从 YAML 种子生成的，我上一版直接手改了生成物导致漂移。已改为在种子（website/config-reference/process.yaml）里补句子并重新生成，第二轮全绿。

PR #3790 现在处于可合并状态（master 又前进了几个提交，属正常漂移；合并由人来操作）。P1–P4 的决策项仍在上面那条回复里等你拍板。

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 (ai: vllm-qwen/qwen3.8-27b)

新子机制条目登记(#3823):第五例同症状实例(v0.1.202, node v24.21.0, win32-x64)机制不同于前三例——内置引擎可用(engine bootstrap: not-needed),失败在 OS 拒绝打开 index.db(SQLITE_CANTOPEN unable to open database file),疑似 Win10 机器环境因素(Defender 锁目录 / OneDrive 占位 / MAX_PATH)。reporter 已确认同版本 Win11 机器正常,排除版本回归。取证清单已发(日志行、目录列表、OneDrive、Defender 排除项、并发实例),等待回报。

无需决策的止血面改进已开 PR:#3855 —— win32 × CANTOPEN 时,降级告警与诊断 reason 点名 AV/OneDrive/路径长度三个嫌疑并纠正「删文件」误导(其他平台/错误类型字节级不变)。注意与在途 #3531(同一 warn 行的缺引擎提示)条件互斥、可组合。

待 reporter 证据到位后处置:确认环境因素 → 本条标记「环境根因,解法=AV 排除」结案;若发现代码侧可复现缺陷 → 按新机制继续修。

fix: surface SQLite bootstrap cooldown expiry and force-retry path in…

docs: document the SQLite bootstrap cooldown marker and force-retry l…

The self-bootstrap path got two fixes in #3819 (merged, next release): a cached-but-unloadable engine copy is now deleted and re-downloaded from the pinned mirror instead of being skipped forever, and a download that succeeds but fails to register arms a cooldown and reports failed honestly. If your case is the unloadable-cache class this should clear it on next start. Could you retest on the next release (≥0.1.204) and report whether the unified sidecar failed to open warning still appears? If it does, the engine probe log line just above it will say which engine was attempted — that string decides whether this is a new platform case.

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 (ai: vllm-qwen/qwen3.8-27b)

#3823 子机制条目更新(机制修正):

AV/Defender 锁文件的假设未获证实,已降级。报告者机器取证:无 index.db/-wal/-shm 残留、日志零 [storage] 行、sessions 目录对低完整性 pwsh 可写、OneDrive 排除。
新线索(高置信):该机器 DSH 沙箱把 bili 子进程压到低完整性——CA bundle 写入被 Windows 完整性控制拒绝(EPERM -4048),用 icacls /setintegritylevel Low 修复后代理才起来。index.db 的 CANTOPEN 与之为同一受限进程根因的两面是当前的领先假设。
「日志零 [storage] 行」的两个候选解释:A) 10MB 轮转把启动行挪进 bili.log.old(待报告者确认);B) logger 静默丢失缺陷——异步打开失败不告警 + [noise] 观测噪音三件:启动横幅同秒重复 24 次 / reasoning-pair-violated 每请求重报(单会话 276 条) / %TEMP% 端口日志无轮转(5 天 31.7MB) #2864 静音竞态导致双通道全死,已立项 All logs silently lost when the log file fails to open: no warning on async open failure, stderr fallback permanently si | 日志文件打不开时全部日志静默丢失：异步打开失败不告警、stderr 兜底被永久静音 #3857,修复在 PR [PR] fix(logger): log file open failure now warns + falls back to stderr instead of total silent loss #3858(打开失败现在打一条 [warn] 并退回 stderr-only)。
PR [PR] fix(storage): name OS-level suspects in win32 CANTOPEN degrade output (#3823) #3855(win32 CANTOPEN 提示)已补充「受限/沙箱进程」为原因项(049c217)。

docs(config): regenerate config docs — drop stale pre-#3818 storage r…

docs: regenerate config-doc artifacts — drop stale duplicate storage …

docs: regenerate config reference (collapse merged duplicate rows)

docs: regenerate CONFIGURATION (drop stale storage.unified shadow row)

fix: regenerate config docs to drop stale storage rows left over from…

fix(docs): regenerate config docs — drop stale duplicate storage rows

docs: regenerate config reference to drop stale duplicate storage rows

docs: regenerate CONFIGURATION to drop 4 stale duplicate storage rows (…

The bootstrap path this report traced has been hardened since v0.1.201:

multi-mirror fallback for the engine tarball (npm canonical → npmmirror, SQLite unified storage degraded to legacy-only (bili v0.1.197, node v20.19.5, win32-x64) #3338/feat: multi-mirror fallback for SQLite engine self-download + Node-upgrade hint in degrade output #3489);
an unloadable cached engine copy is now deleted and retried once via a pinned download instead of being trusted forever (engine-bootstrap.ts cache re-validation);
a download that succeeds but fails to register reports failed + cooldown instead of a lying downloaded.

So on ≥0.1.204 the expected outcome on this machine is full (or at worst a one-time retried download), not a silent legacy-only degrade. Could you retest on the next release and drop the /__bili/status storage blob here? If full mode still fails to engage on win32/x64 node 20.x, that's a fresh bug and this can be reopened with the degrade output.

🤖 Powered by ework · qwen3.8-27b

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

请报告者用 ≥v0.1.204 复测(存储收尾第二波 #3901 的 A3 项)。

你报的失败机制(引擎自下载单源不可达 → win32 + Node 20 停在 legacy-only)已在 master 修复并核实:

多镜像回退:引擎自下载现在走有序链 registry.npmjs.org → registry.npmmirror.com,每源独立 60s 预算、每源 sha512 pin、全失败才进 6h cooldown 且 reason 枚举尝试过的源(src/storage/engine-bootstrap.ts);
升级 Node 提示:降级 warn 行与 diagnostics/web 的 degrade reason 均追加「升级 Node(自带 node:sqlite)可跳过下载」提示——你的机器是 Node v20.19.5,升到 Node ≥22.5 后内置 node:sqlite 直通 full 模式,彻底不需要下载;
引擎失败路径也已加固:不可加载的缓存副本会被清掉并用钉死源重试一次。

复测步骤:更新到 ≥v0.1.204(或直接把 Node 升到 22.5+),重启 bili,看启动日志里 [storage] 是否还有 unified sidecar failed to open ... staying legacy-only;web 面板 diagnostics 的 degrade reason 应为空。若仍降级,把完整 degrade 输出贴回来重开本单。

@bjssliu

🤖 Powered by ework · qwen3.8-27b

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

已对 master（5121f45f8）逐条核实。三条加固都在，其中一条缺回归测试——已顺手补上：

① 多镜像回退 ✓
src/storage/engine-bootstrap.ts:359-378：按序走镜像（配置的 registry 优先，再 npm canonical → npmmirror），单镜像失败记 "trying next mirror"，全耗尽时错误带 (tried mirrors: …)。三个场景都有测试钉住：回退成功 / 耗尽列全镜像 / 配置源优先（tests/storage-engine-bootstrap.test.ts:817/843/872）。

② 缓存副本不可加载 → 删除 + 钉死重下 ✓
engine-bootstrap.ts:226-242（#3135-5）：cacheUsable 通过但加载失败 → 删目录、落回一次 sha512 钉死的重下。测试在 line 372（"#3818 unloadable cached copy is removed…"）。

③ 下载成功但注册失败 → failed + cooldown ✓（原先没有测试）
engine-bootstrap.ts:262-270（commit 11e5bda）：字节落盘但引擎加载不了 → status=failed（detail=post-download registration failed）+ 置 6h cooldown，不谎报 downloaded。但该 commit 只改了 +10/-1 行、无配套测试，tests/ 全库检索确认缺失。若此路径回归，面板会显示 downloaded 而实际静默 legacy-only——正是 #3788 这类报告的盲区。已当场修：PR #3930（记录 issue #3929，带来源标记）补一条 hermetic 测试（sha512 合法但 lib/index.js require 即抛错的 tarball → 断言 failed + marker 写入 + 下一轮 cooldown 门控零重下载），本地定向 31/31 + typecheck 干净，等 CI。

另核实：默认 unified 模式已翻转为 full（#3818；src/knobs.ts:759 未设置时返回 "full"）——该机器没设 storage.unified，所以引擎一旦可用，effective 就是 full，与你的预期一致。

⚠️ 时间线事实：最新 release tag 仍是 v0.1.202，上述加固（含 full 翻转）目前都只在 master，尚未发版；≥0.1.204 还不存在。所以真机复测被「先发一版」卡着，而发版需要你批准——要推进的话请在本线程批一下（v0.1.203 或你定的号），我立刻备 release PR。

关于「retest」：我够不到 @bjssliu 的 Windows 机器，无法字面复测。替代做了本地 hermetic 仿真（Linux）：seam 模拟「无 node:sqlite + 无宿主 better-sqlite3」+ mock registry/镜像，把下载成功、镜像失败回退、注册失败、cooldown 门控全部路径跑绿。逻辑层面验证通过；win32 特有因素（AV 隔离、企业代理、出口网络）只能真机验。新版发出后请用户：等自动更新（bili --version 确认），重跑同一份诊断、贴 storage 段过来；effective 仍为 legacy 就带 degrade 输出按新 bug reopen。

上一轮 P1–P4 决策项现状（如实报）：

P1（cooldown marker 带版本戳）：仍开放 —— CooldownMarker 还是 {atMs, reason}（engine-bootstrap.ts:142-145），旧版本写入的 marker 仍能压住新版本的改进重试；
P2（强制重试命令面）：手动杠杆可用且已文档化/诊断可见（删 marker 文件 + 重启，[PR] fix: surface SQLite bootstrap cooldown expiry and force-retry lever in storage diagnostics #3790 已并入 master），但没有专用命令；
P3（按失败类别区分 cooldown）：未做，仍是单一 6h；
P4（长驻宿主进程重启前不再 bootstrap）：仍开放 —— ensureSqliteEngine 每进程一次性（src/cli.ts:619、src/inline-engine.ts:328）。

八问（决策请求版）：

是什么问题：核验本条评论所述加固是否真实落在 master，并确定复测路径。
什么原因导致的：不涉及（核验工作，非缺陷修复）。
影响范围与严重程度：三条加固全部存在；唯一缺口是③的测试缺失——无外部影响，只影响未来回归防护。
怎么修复的：PR [PR] Add regression test: SQLite engine bootstrap reports failed+cooldown when a downloaded engine won't register #3930 补一条 hermetic 回归测试，零生产代码改动。
是否有回归问题：无——纯测试新增，不触碰任何执行路径。
是否破坏缓存：不涉及。
是否改了设计方向：无。
是否引入新配置：无。

请拍板两件事：① 批准一个包含上述加固的新版（≥v0.1.203）以解锁真机复测；② P1/P4 关单还是继续（继续的话我按一个 follow-up PR 实现，不拆片）。

🤖 Powered by ework · qwen3.8-27b

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

登记本家族新子机制条目:index.db 文件本身损坏(与引擎下载失败主线、#3823 win32 CANTOPEN 均不同机制)。

实例:SQLite unified storage degraded to legacy-only (bili v0.1.202, node v24.21.0, darwin-x64) index.db corrupted | SQLite unified storage degraded to legacy-only (bili v0.1.202, node v24.21.0, darwin-x64) index.db损坏 #3959(v0.1.202,node v24.21.0,darwin-x64)——引擎正常(node:sqlite builtin,bootstrap not-needed),损坏的是索引文件本身(open 报 "database disk image is malformed"),sidecar 每次重启都重新失败,永久锁死 legacy-only,直到人工删文件。
根因:corruption 类 open 失败只有降级路径([Bug][storage] corrupt index.db bricks SessionStore construction in shadow/full mode (violates the sidecar never-breaks-legacy policy) #2771 的「删除文件」人工恢复策略),无自愈分支。
修复:[PR] fix: auto-quarantine a corrupt index.db instead of degrading to legacy-only forever #3965——仅对 corruption 类错误自动隔离(改名 .corrupt-<ts>,永不删除、留作取证)+ 立即开新索引;非 corruption 类(CANTOPEN/权限/无引擎等)降级路径逐字节不变。Closes SQLite unified storage degraded to legacy-only (bili v0.1.202, node v24.21.0, darwin-x64) index.db corrupted | SQLite unified storage degraded to legacy-only (bili v0.1.202, node v24.21.0, darwin-x64) index.db损坏 #3959。

@zypNB123

The engine tiering just landed on master (#3963, from @zypNB123's #3896): Node 20 no longer depends on the v13-only artifact — it now resolves a pinned better-sqlite3 v12.9.0 with ABI-matched prebuilds (same unified-storage lane, no legacy degrade), and any runtime no artifact can serve is refused before load instead of crashing.

Could you retest on the next release (≥ 0.1.204) with the same Node v20.19.5 and report whether the sidecar comes up (/__bili/status → storage → effective mode)? If it still degrades, the new diagnostics will name the exact artifact/ABI that failed to resolve — that detail will pin the remainder.

docs: drop stale duplicate storage rows from generated config referen…

Navigation Menu

Repository navigation

SQLite unified storage degraded to legacy-only (bili v0.1.201, node v20.19.5, win32-x64) #3788

八问

选项对比表

5 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

SQLite unified storage degraded to legacy-only (bili v0.1.201, node v20.19.5, win32-x64) #3788

Description

Activity

ranxianglei commented on Oct 19, 2026

ranxianglei commented on Oct 19, 2026

八问

选项对比表

ranxianglei commented on Oct 19, 2026

ranxianglei commented on Oct 19, 2026

ranxianglei commented on Oct 19, 2026

ranxianglei commented on Oct 19, 2026

5 remaining items

ranxianglei commented on Oct 20, 2026

ranxianglei commented on Oct 20, 2026

ranxianglei commented on Oct 20, 2026

ranxianglei commented on Oct 20, 2026

ranxianglei commented on Oct 20, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions