Skip to content

Storage wrap-up: 6 fixes + switch default mode to full (single PR) | 存储收尾六修 + 缺省模式翻 full(一个 PR 统一处理) #3818

New issue
New issue
Closed
#3819
Closed
Storage wrap-up: 6 fixes + switch default mode to full (single PR) | 存储收尾六修 + 缺省模式翻 full(一个 PR 统一处理)#3818
#3819
Labels
p2scope/storage

Description

@ranxianglei
ranxianglei
opened on Oct 19, 2026

一句话

把 SQLite 统一存储的缺省模式从 shadow 翻到 full,同车收掉 #3135 的六个收尾缺陷——翻完后面板不说谎、极窄窗口不丢拍、供错数可见可回退,一个 PR 全部处理。

为什么要翻

六项收尾(全部吸收自 #3135,行号见原文)

  1. 自禁用瞬间丢最后一拍(jsonWriter=off 场景):persist.ts writerOff 分支在 guardedBuild()() 之后复查 shadow.stats.disabled,翻转了就同步补 arm 一次 JSON 写。
  2. BILI_PERSIST=0 常驻假「存储降级」横幅:!enabled 时按加密同样的路径记 intentionalOptOut,runtime-status.ts 的 degraded 判定不再恒真。
  3. storageMode 印章盖的是"请求的"不是"实际开成的":sidecar 开失败(shadow===undefined)时印章写 legacy(建 store 时定一次),web 面板与实际一致。full 翻默认后此项从"瑕疵"变"必须"——node<22.5 且引擎下载失败的机器(SQLite unified storage degraded to legacy-only (bili v0.1.201, node v20.19.5, win32-x64) #3788 这类)会大量处于"请求 full、实际 legacy"状态。
  4. digest 漂移静默供错数:verifyDrift 加进 storageStatusWire 载荷;full 且 JSON 还在写时,漂移会话回退 JSON 信封读。full 作为事实源后这是正确性要求。
  5. 引擎缓存"在但加载不动"永远不重下:tryRegisterFromCache 抛错(如 .node ABI 不匹配)时 rm 缓存并放行一次正常下载(sha512 钉死使其安全),不再每次 boot 永久降级。
  6. bootBounded(限量启动)跳过索引并集:按同样限额对 listSessionIds() 跑并集,jsonWriter=off 的纯索引会话在限量启动下可见。

翻转本身

验收

  • 每项一条测试:stamp 与实际一致 / drift 上报+回退读 / PERSIST=0 无横幅 / 自禁用拍不丢 / 坏缓存重下 / 限量启动并集可见;
  • 无配置新装实例:effective mode=full;
  • BILI_STORAGE_UNIFIED=legacy:一键回 legacy,JSON 权威;
  • 现有全量测试族(storage-unified / golden-storage-render / runtime-status)零回归。

明确不在本 PR

#3399(账本冷启动,另修)、#3798(增量车道独立灰度)、#3463(GC)、#3489(镜像 fallback)。

Fixes #3135

Activity

  1. ranxianglei
    changed the title [-]存储收尾六修 + 缺省模式翻 full(一个 PR 统一处理)[/-] [+]Storage wrap-up: 6 fixes + switch default mode to full (single PR) | 存储收尾六修 + 缺省模式翻 full(一个 PR 统一处理)[/+] on Oct 19, 2026

  2. ranxianglei commented on Oct 19, 2026

    @ranxianglei
    ranxianglei
    on Oct 19, 2026
    OwnerAuthor

    实现完成,PR #3819(缺省翻转 + 六项同车修,打桩先行七红七绿):#3819

    要点:

    1. 缺省 shadow→full(knobs.ts 一行 + 注释/文档),JSON 信封照写,legacy 逃生口不变;
    2. 六项全落:Storage Subsystem Wrap-up Checklist (#3130 Review): Dropping the last tick upon self-disable; BILI_PERSIST=0 falsely triggering a "Storage Degraded" banner; storageMode stamp mismatched with the actual enabled mode; and 3 more (6 items total) | 存储子系统收尾清单… #3135-① writerOff 当拍补写 JSON / ② 持久化关闭=有意退出 / ③ 印章盖实例真实模式 / ④ verifyDrift 上 wire+漂移会话回退信封 / ⑤ 自举缓存坏了删了重下一次 / ⑥ 有界 boot 并入纯索引会话。

    七桩先行(tests/storage-full-flip.test.ts 6 + engine-bootstrap 1),全部先红后绿;家族回归 storage-replicas/golden-storage-render/acp-status/memory-diagnostics 全绿;CONFIGURATION(+zh)与 website 种子已重生成。全量本地跑与 CI 在路上。

  3. ranxianglei
    added 3 commits that reference this issue on Oct 19, 2026

    fix: bounded-boot index union skips file-backed ids to honor the deco…

    0746349

    test: align storage banner/mode-label suites with the full default (#…

    64c860f

    fix: arm cooldown when post-download engine registration fails (#3818 …

    11e5bda

  4. ranxianglei commented on Oct 19, 2026

    @ranxianglei
    ranxianglei
    on Oct 19, 2026
    OwnerAuthor

    🤖 Powered by ework · qwen3.8-27b

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

    查重: 不重复(##3818 是 owner 设计的单 PR 整合项)。但发现一条在途重叠:PR #3144(10-14 开,Closes #3135)已独立实现了同样的六项收尾,与本项 PR #3819(今日开,flip + 同六项)在 src/persist.ts / src/storage/* 上大面积重叠。两者都合并必冲突。按 issue 正文「一个 PR 全部处理」的设计,#3819 是超集(多出缺省翻转),建议以 #3819 为准、#3144 作 superseded 关闭——最终由你拍板,我不动 #3144。

    标签: scope/storage、p2(存储域收尾 + 缺省模式翻转;非缺陷报告不打 bug,无特定客户端)。

    当前状态: PR #3819 存在且 open(分支 2026-10-19_storage-full-flip,behind master)。正在核对代码与 CI,结论稍后按八问体例跟帖。

  5. ranxianglei
    added
    p2
    scope/storage
    on Oct 19, 2026
  6. ranxianglei
    added 3 commits that reference this issue on Oct 19, 2026

    storage: orphan-contents guard + bounded-boot byte budget (#3818 foll…

    9a16af6

    test: close per-leg stores in the web-sessions stamp test (#3818 review)

    78c38e2

    test: pin #2695 reap-shape records as envelope-served across restart (#…

    21b70f4

  7. ranxianglei commented on Oct 19, 2026

    @ranxianglei
    ranxianglei
    on Oct 19, 2026
    OwnerAuthor

    🤖 Powered by ework · qwen3.8-27b

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

    进度更新：PR #3819 的 4 条红 CI 已全部根因定位并修复，等 CI 收尾。

    验证过程中发现分支上并行落了一个同题修复（9a16af66e，orphan-contents guard + bounded-boot 字节预算 + merge master），与我的独立分析撞车。处置（union of intent）：

    1. 本地核验其实现：全 PR 触碰面 12 个测试族 98/98 绿（含原先红的 bounded-storage-scale / identity-registry / web-sessions）。其设计比我的更干净——guard 直接跳过镜像（orphanSkips 计数）+ loadSync 供数改走无损的已解析信封视图，我放弃了自己那份重复的 fix commit。
    2. 补了两个标注 commit 推上 PR 分支（head 现 21b70f4）：
      • test: close per-leg stores in the web-sessions stamp test——并行版每个 leg 的 store 没 closeQuietly，Windows 上 index.db 句柄可能活过 rmrf(dir)，teardown 有 flake 风险；
      • test: pin #2695 reap-shape records as envelope-served across restart——stake-8 回归钉。
    3. 一处事实更正：9a16af66e 提交信息称「Real kernel sessions never trip this」——不成立。[Bug][proxy] unframed host-side history deletion leaves zombie fold blocks rendering carriers forever — one carrier flaps in/out every turn (persistent prefix-cache churn) #2695 reapDestroyedSubstrate 正是真实内核会话产生该形状（state.blocks 过滤、blockContents 保留供 decompress 兜底），stake-8 测试钉的就是这个形状。
    4. 跨重启残留已立项 Reaped blocks resurrect after restart in full mode: stale index row outlives the #2695 reap and poisons the JSON envelope #3841（带来源标记）：reap 前的合法索引行跨重启存活 → 重启后 block 复活、envelope 被污染；当前 guard 只拦首次入库，driftedSessions 是内存态。修法涉及持久化格式（schema v6 候选），等你拍板。

    CI 在 21b70f4 上跑着（gate/docs/kernel-guard/unused-exports 已绿，8 条 test lane + static-gates 进行中），出结果后按八问给最终结论。

  8. ranxianglei commented on Oct 19, 2026

    @ranxianglei
    ranxianglei
    on Oct 19, 2026
    OwnerAuthor

    🤖 Powered by ework · qwen3.8-27b

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

    PR #3819（head 21b70f4）CI 全绿：17/17 通过，0 失败（其余为路径门控 skip）。验收对照：无配置新装 effective=full ✓（test ①）、BILI_STORAGE_UNIFIED=legacy 一键回退 ✓、storage-unified / golden-storage-render / runtime-status 族零回归 ✓、六项各一条测试 + 验证期新发现的第七项（孤儿内容 guard）也有回归钉。

    八问：

    1. 是什么问题：把统一存储缺省从 shadow 翻到 full，并收掉翻越前遗留的六个收尾缺陷——翻完后面板不说谎（印章=实际模式）、自禁用当拍不丢最后一拍、digest 漂移可见可回退、坏引擎缓存能自愈、限量启动不丢纯索引会话。
    2. 什么原因导致的：六项全是 shadow 干跑期「反正 JSON 是事实源」掩盖掉的边角——写路径只保一边、观察面缺失、印章盖请求值而非实际值。验证期另发现一个真缺陷：[Bug][proxy] unframed host-side history deletion leaves zombie fold blocks rendering carriers forever — one carrier flaps in/out every turn (persistent prefix-cache churn) #2695 reap 形状的记录（state.blocks 移除条目、blockContents 保留文本）索引无法表示，首载会静默丢内容且下次保存污染两份存储——已加 orphan-contents guard（入口跳过镜像 + 信封供数 + orphanSkips 计数）。注意：并行提交的「real kernel sessions never trip this」判断不成立，reap 形状正是真实会话产生的，stake-8 测试钉的就是它。
    3. 影响范围与严重程度：所有无配置实例的默认读路径变更；修复前六项各自 p2~p3（面板说谎、丢拍窗口、静默供错数），孤儿形状缺陷在翻默认后升级为数据完整性问题（已修）。node<22.5/引擎下载失败机器自动留 legacy，是设计内安全网。
    4. 怎么修复的：每项一个机制级修法（见 PR diff）+ orphan guard 三道闸（record/importRecord 入口跳过不可表示记录、loadSync 供数改走无损的已解析信封视图、bootBounded 并集受 maxSessions+解码字节双预算）。验证中与并行落地的同题实现（9a16af66e）撞车：本地核验其 12 个测试族 98/98 绿后采纳（设计更干净），撤回我的重复 fix，补两个标注 test commit（Windows 句柄安全 closeQuietly + stake-8 跨重启 reap-shape 钉）。
    5. 是否有回归问题：逐项审过——显式层级语义不变（显式 legacy/shadow 行为同前）、JSON 始终在写（full 非单副本）、逃生口生效、出站渲染未触碰（快照渲染灰度不受影响）；CI 全绿 + 本地定向 98/98。残留一处已立项 Reaped blocks resurrect after restart in full mode: stale index row outlives the #2695 reap and poisons the JSON envelope #3841：reap 前的合法索引行跨重启存活 → 重启后块复活 + envelope 污染，需 schema 级决策（orphans_json 列 vs discriminator vs 加载期探测），不在本 PR 范围内硬修。
    6. 是否破坏缓存：不涉及——前缀缓存/重试/去重键未触碰，只动持久化读路径的事实源选择。
    7. 是否改了设计方向：方向未变，是既定 rollout 的下一步：统一索引从对账副本升为缺省事实源，JSON 降为权威备份 + 逃生口。
    8. 是否引入新配置：无新 key。已有行为的披露：storage.unified 缺省 shadow → full（理由：双写对账一个多月干净 + 快照渲染/增量车道地基）；印章语义从「写入时解析旋钮」改为「建 store 时冻结实例实际态」（item ③ 本意）；status wire 增 verifyDrift/driftedSessions 字段、stats 增 orphanSkips（均为 additive）。

    两件事等你拍板：

    判定：可合并（merge 由你执行：https://github.com/ranxianglei/billion-context/pull/3819）。标签此前已打：scope/storage + p2。

  9. ranxianglei commented on Oct 19, 2026

    @ranxianglei
    ranxianglei
    on Oct 19, 2026
    OwnerAuthor

    🤖 Powered by ework · qwen3.8-27b

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

    收到。这条实现报告与我已完成的核验对上了——补充当前状态（详见楼上八问回复）：

  10. ranxianglei
    added a commit that references this issue on Oct 19, 2026

    storage: writerOff safety valve for unrepresentable records (#3818 re…

    6d36b45

  11. 40 remaining items

  12. Zhishulo
    added a commit that references this issue on Oct 20, 2026

    test: stop a stray Windows handle from failing the full-flip suite

    6c185bc
  13. ranxianglei
    added 4 commits that reference this issue on Oct 20, 2026

    test(#3769): pin full mode in the upgrade-compat suite

    14f9c95

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

    22477f5

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

    81f6654

    Merge pull request #4097 from ranxianglei/2026-10-21_full-flip-determ…

    e1bf1b5
  14. Zhishulo
    added a commit that references this issue on Oct 21, 2026

    fix(ci): flush the v2 envelope synchronously in the ranxianglei#3818 …

    8f2332f
  15. ranxianglei
    added 9 commits that reference this issue on Oct 21, 2026

    docs: align the ranxianglei#3818 parsed-view note with the orphan jou…

    ba2398d

    test: pin exact orphan content bytes in the writerOff reap-shape test (…

    1fcc87f

    test: re-pin storage-lane proofs onto the #4316 one-time ledger align…

    18f5146

    fix(tests+cli): align three suites with the no-degradation contract

    627c258

    docs(review nits on #5475): correct the unified-storage flip release …

    e12c6e3

    fix: correct stale storage.unified default comment (absent defaults t…

    4480ed6

    docs(tests): correct stale storage-default comment in preload-storage…

    3396a40

    docs(tests): correct stale storage-default comment in preload-storage…

    8393dee

    fix: correct stale storage.unified default comment (absent defaults t…

    05a4d94
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    p2scope/storage

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions