DSH raised a version storage layer issue during self-check. I'm unsure of the severity or urgency, so I'm sharing it her | DSH在自检时提出了版本存储层问题，我不确定严重性和急迫性，在此分享。

0.1.212 在当前这个会话里反复报存储一致性错误（另一条会话的缓存并没有受影响）：
代码块
[storage] unified shadow DIGEST DRIFT … diverged: lastMessages; tail slot 15
[storage] DIGEST DRIFT ESCALATED: 3 consecutive sampled drifts
[persist] skipping scheduled envelope save — JSON envelope writes FROZEN since 2026-11-04T11:14:57Z
也就是说，这个会话的 JSON 信封的写入被冻结了（SQLite 仍在写）。这是 0.1.212 的存储层问题，建议报给 bili 的 issue tracker，或者在确认前先不要频繁重启，否则可能出现“信封落后于日志”的状态（相关日志在 bili.log）

bili.log

🤖 Powered by ework · qwen3.8-27b

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

查重：不重复于任何 open issue；与已关闭的 #4392（v0.1.204 反复 DIGEST DRIFT）属同一症状家族，且你的日志显示该家族从 v0.1.204 一路复发到 v0.1.212、跨多个会话——本条作为当前活跃实例保留；与 #5408（冻结信封可见性，已在 0.1.212 修复）机制不同。
标签：bug / dsh / scope/storage / p2（缺陷 + dsh 车道 + 存储层 + 能用但有明显问题）。

先说结论：这不是数据丢失，重启是安全的，冻结期间无需任何特殊操作。

按八个问题逐项答：

是什么问题：这个会话的存储双副本（JSON 信封 vs SQLite 统一库）里有一条短 assistant 消息字节对不上，每约 20 次保存采样一次、次次不一致；连续 3 次后系统按设计冻结该会话的 JSON 信封写入（防止两副本互相覆盖），SQLite 则全程照写。只影响这一个会话，其他会话不受影响——与你观察到的「另一条会话缓存没受影响」一致。
什么原因导致的：两条副本在同一进程内由同一份内存数据构建，漂移说明「存下来的行 ≠ 活数据」。从你的日志看：两侧 id 相同（id 由全文派生，id 不变 ⇒ 文本没变），但长度差在两个值之间来回翻转 ⇒ 变的是某个非文本字段（位置戳/时间戳一类）。叠加一个结构性问题：增量快速路径按设计跳过水位线以下的槽位，宿主每轮改写该槽位 ⇒ 每次修复后 ≤20 次保存内再次分歧 ⇒ 「drift resolved」永远无法触发 ⇒ ESCALATED→FROZEN 慢性循环（报警文本点名的 SQLite unified storage degraded to legacy-only (bili v0.1.205, node v24.22.1, win32-x64) #4614 类生产者）。具体是哪个字段，现有诊断看不到（隐私设计不落正文进日志）——这正是本次修复要补的。
影响范围与严重程度：仅该会话。无功能损失（压缩、缓存、续接都走内存，SQLite 全程在写）；重启安全——冷加载的新鲜度比对会选更完整的那一份，冻结期间 SQLite 一直领先，你担心的「信封落后于日志」回退不会出现。实际退化 = 错误日志刷屏 + 该会话的信封文件停更。定级 p2：能用、有明显问题、有绕行（继续用或随时重启都行）。
怎么修复的（PR [PR] fix(storage): add field names to drift diagnostics + disable incremental fast path during drift latch (#5677) | fix(storage): drift 诊断补字段名 + 漂移锁存期间停用增量快速路径 (#5677) #5679，两层）：
- 诊断层：漂移日志行现在会报出首个分歧槽位的差异字段名（排序、仅名单、值不进日志，与既有指纹同一隐私契约）。升级后下次出现就能直接看到是哪个字段在变，从而钉死生产者；
- 收敛层：会话处于漂移锁存期间停用增量快速路径，每轮走全量精确路径 ⇒ 采样时两条腿恒为同代 ⇒ 下一采样通过 ⇒ 自动解锁、增量恢复。把慢性冻结循环变成有界自愈事件：这类场景今后退化为「偶发单次漂移报告（带字段名）+ 短时全量写入」，不会再升级到冻结。成本只由「已被证明分歧」的会话承担，健康会话零影响。
是否有回归问题：审过的既有行为——增量快速路径对非锁存会话的行为逐字节不变（代码路径未动）；漂移日志行仅在尾部新增可选 ; fields: … 段，前缀逐字节不变，既有 grep 不受影响；异步路径与同步路径同口径加了同一道门（沿用 Async storage backend: drift latch never releases once engaged — every save full-reingests forever (#5409 B1 not ported) #5412 的 parity 惯例）。无其他语义变化。行为变更披露：旧 = 漂移修复后最多 ≤20 次保存可继续走增量（期间宿主改写会再次制造分歧）；新 = 锁存期间一律全量精确路径直到一次干净采样重新准入。
是否破坏缓存：不涉及——不动出站字节与前缀缓存，纯服务端存储层诊断与收敛策略。
是否改了设计方向：没有——仍是双副本 + 采样校验 + 水位线，只是收紧了锁存期的信任边界（「已被证明不可信时不用快速路径」）。
是否引入新配置：没有。

PR：#5679 （Refs 本条——根因还差最后一步：等新版上线后下次漂移报出字段名，即可钉死具体是哪个字段在变；本条保持打开到生产者确认。）

补充一点：你的日志里 10 月 25 日有一条「另一个 bili 实例正在同一车道运行」的警告。如果你在其他地方同时跑着指向同一会话目录的 bili 实例，建议先停掉——那是另一个已知的写干扰源（#394）。不过本条的主模式与上述单宿主改写更吻合，双实例只是排查清单里的一项。

fix(test): number the drift diag suite by its GitHub issue + pin the …

是不是可以直接停止json会话?ework告知方式

🤖 Powered by ework · qwen3.8-27b

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

可以直接停，而且不用开发——开关已经存在（#2960 Phase 3）：

// ~/.config/billion-context/billion-context.json
{ "storage": { "jsonWriter": "off" } }
// 或环境变量 BILI_STORAGE_JSON_WRITER=off（env 优先）

生效前提：本地 SQLite 后端 + unified=full——两者都是默认值，报告者的环境直接满足。
效果：JSON 信封彻底不写，SQLite 成为唯一持久副本；该会话自然也不再有「信封冻结」状态。
回滚：去掉配置即恢复双写；期间只写索引的会话照常加载，replicas/restore 可重新物化信封。

两个诚实边界：

这是「删掉一份副本」，不是修漂移源头。采样校验在 jsonWriter=off 下依然运行——它比的是内存视图 vs SQLite 行（recordToLegacyView 从内存构建，不读 JSON 文件），与信封写不写无关。所以宿主改写历史的话 drift 日志行还会出现，但不再有冻结、不再有「信封落后」的担心。慢性不收敛本身由 PR [PR] fix(storage): add field names to drift diagnostics + disable incremental fast path during drift latch (#5677) | fix(storage): drift 诊断补字段名 + 漂移锁存期间停用增量快速路径 (#5677) #5679 修（锁存期走全量精确路径→下一采样通过→自动解锁），两者互补：[PR] fix(storage): add field names to drift diagnostics + disable incremental fast path during drift latch (#5677) | fix(storage): drift 诊断补字段名 + 漂移锁存期间停用增量快速路径 (#5677) #5679 治循环，jsonWriter=off 是「我就是要单副本」的出口。
切换后若 index.db 自身损坏，没有第二份副本兜底。安全网仍在：损坏会被 quick_check 拦下、无索引启动+大声报警、且该模式下会临时恢复 JSON 写入做应急持久化（进行中的回合不丢），但历史状态恢复依赖手工修复索引。这也是我建议不改全局默认的原因——迁移期双写是回滚保险；想要零 JSON 写的用户自己开即可。

告知方式：现有通道是 web 面板横幅 + /__bili/status（attribution 字段，#3581）、冻结态可见性（#5408，0.1.212 已带）+ bili.log 错误行——这次用户实际是 dsh 自检读日志发现的。如果想要「冻结发生时主动提示一次」（比如面板一次性横幅），可以挂到现有公告注册表（#5548）上做内置通知，改动很小，要的话我来加。如果你说的「ework 告知方式」是另一个意思（平台侧通知链路？），说一声我再展开。

Merge origin/master into PR #5679 head — resolve shadow.ts ingest-pat…

Merge pull request #5679 from ranxianglei/2026-11-04_drift-field-diag

fix(storage): name divergent drift fields and force the full path whi…

fix(storage): align the envelope tail leg to the row tail by suffix

Navigation Menu

Repository navigation

DSH raised a version storage layer issue during self-check. I'm unsure of the severity or urgency, so I'm sharing it her | DSH在自检时提出了版本存储层问题，我不确定严重性和急迫性，在此分享。 #5677

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

DSH raised a version storage layer issue during self-check. I'm unsure of the severity or urgency, so I'm sharing it her | DSH在自检时提出了版本存储层问题，我不确定严重性和急迫性，在此分享。 #5677

Description

Activity

ranxianglei commented on Nov 4, 2026

ranxianglei commented on Nov 4, 2026

ranxianglei commented on Nov 4, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions