Skip to content

Does the original session trimming class in dsh-filesnap cause a conflict? | dsh-filesnap原始会话删减类是否冲突 #5923

New issue
New issue
Open
Open
Does the original session trimming class in dsh-filesnap cause a conflict? | dsh-filesnap原始会话删减类是否冲突#5923
Labels
bugSomething isn't workingdshneeds-decisionp2scope/storage

Description

@ranxianglei
ranxianglei
opened on Nov 8, 2026

https://github.com/extracurricular-ai/dsh-filesnap

bili.7z

用户崩溃日志

Mirrored from ework issue #5925

Activity

  1. ranxianglei commented on Nov 8, 2026

    @ranxianglei
    ranxianglei
    on Nov 8, 2026
    OwnerAuthor

    🤖 Powered by ework · qwen3.8-27b

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

    查重: 不重复——本线是已闭 #4614「子缺陷 B」的后续跟踪条目(同症状、同机制:host 每轮改写水位线以下的历史槽位 → 采样校验永不收敛 → 升级冻结),#4614 关闭时明确留了待拍板的选项 1/2/3 并邀请追条,本线即该追条;与几个开放条目同症状家族但机制不同:#5624(omp 车道 fork 会话漂移,升级到 v0.1.212 后自愈,分歧形状是 id 互换)、#5885(dsh rewind fork+seed 的折叠域退化)、#5106(SQLite 往返自洽性假设,未证实)。

    标签: bug + dsh + scope/storage + p2(缺陷类;dsh 插件车道;存储层双份副本漂移冻结;目前仍可用、无数据丢失实证 → p2,p1 级复合窗口见影响一节)

    结论先行

    filesnap 的删减类本身不与 bili 冲突。 我通读了它的源码(main @ 832387b):rewind = fork 出新会话(新 session id + 种子历史前缀)+ 把原会话标题改名(🔴 Inactive ·);结果里的 deleted 计数是 FileSnap 引擎恢复的工作区文件数,不是对话消息;原会话的消息内容从不被修改或删减;它的迁移逻辑是一次性、幂等、只处理旧格式日志、跳过已加载会话且先写备份。对 bili 而言,分支 = 全新会话(全新 ingest),原会话 = 未变的历史——结构上产生不了「水位线下反复改写」。

    但这台用户机器上确实发生了真实冲突,不是 filesnap 引起的,而是已知未决缺陷 #4614-B:dsh host 每轮保存改写同一个历史槽位,bili 增量 ingest 按设计跳过水位线以下的槽位 → 采样校验每轮必中、永远差一个保存周期 → 永不收敛 → 三连升级 → JSON 信封写入冻结。

    日志证据(bili.7z,v0.1.212,单连续进程 11-05T21:53→11-08T12:11,全程无重启/崩溃标记)

    • DIGEST DRIFT 共 100 条(bili.log 27 + .old 73),跨 ≥12 个 dsh 会话;ESCALATED 5 个会话冻结信封(session-685e4228 @11-06T18:26、8cd9623c、session-4b6ccc7b、c0c03bc2、session-363f760f)。
    • 所有漂移都指向同一个 assistant 消息 id h_2446cf3e209693e2:一侧稳定 len=127/sha=c2667072,另一侧 len=148–150 且 sha 逐样本变化;expect/got 值在连续样本间滑动(got@本轮 == expect@上一轮)= 差一个保存周期的经典签名。
    • 跨安装证据:同一消息 id(及同样的 len=127 形状)也出现在 SQLite unified storage degraded to legacy-only (bili v0.1.205, node v24.22.1, win32-x64) #4614 那位 10 月 win32 用户的日志里。消息 id 由内容派生(role|类型|toolName|text 的 sha256)→ 两台无关机器共享字节相同的 assistant 消息 ⇒ 这是宿主/插件注入的固定样板文本,不是用户内容 ⇒ 改写方在 dsh 宿主层、跨安装共有,与本用户个人环境无关。
    • 冻结后健康度:受影响会话照常工作(实测 [acp-usage] input=45358 cached=44160 (cache hit 97%)、折叠干净),统一存储继续接收保存;受损的是 JSON 信封文件(冻结不再更新)+ 大量日志噪音。窗口内无进程死亡——「崩溃」≠ 进程崩溃,日志尾部是正常 parent-gone flush。
    • 附带噪音:preflight 报数百个同基 id 的 _N 碰撞家族副本渲染空文本(h_..._90 rendered no text,数百条占位式短 assistant 消息);慢会话告警(Long sessions starve the event loop: a 4,600-message session blocks the proxy and the web UI for 7–50 s per turn #4528 家族,上游已闭)。

    机制链(为什么不收敛)

    1. bili 增量 ingest 快路径(watermark)只校验边界槽 + 头部槽,水位线以下的槽按设计不重算(影子存储(默认开启)每次落盘把整个会话重新序列化+哈希,大会话明显变卡;jsonWriter=off 时连防抖合并都没了 #3133 成本换时延)——被改写的槽每次 delta save 都被合法跳过;
    2. 采样校验(每 N 次 ingest)比对双份副本,每次必中 → 清水位 → 下次全量 re-ingest 修复 → 但 host 又改写了 → 再差一个周期;
    3. 连续三个样本 → ESCALATED → JSON 信封写入冻结(After idling for one hour, the fold override is lost: the client resends byte-for-byte identical content, and the previo | 闲置一小时后折叠覆盖丢失:客户端重发逐字节不变,已折叠的 ~240K token 内容自己回到上下文 #4323 语义);若此时 sqlite 再降级,两边都丢冻结后状态(SQLite unified storage degraded to legacy-only (bili v0.1.205, node v24.22.1, win32-x64) #4614 实际发生过约 5 小时的数据丢失窗口)。

    已有修复在途

    PR #5679(open,11-04 创建;镜像缓存快照 11-04、sha 4de5cd3:30 项 check 全绿/跳过,mergeable_state=blocked 待人工合并;此后可能已有新提交)针对的正是这一类:漂移锁存期间禁用增量快路径、每轮走全量精确路径 → 采样必然同代通过 → 一个干净样本后解锁,慢性冻结变有界自愈事件;同时给漂移诊断加上首个分歧槽的顶层字段名(; fields: …),能定位到 host 到底每轮改写哪个非文本字段(现有指纹只有 id/role/len/sha8)。用户的 v0.1.212 早于该修复。

    八问

    1. 是什么问题:用户的 dsh+bili 环境出现存储双份副本漂移升级风暴(100 条漂移 / 5 个会话信封冻结),询问 filesnap 原始会话删减功能是否与 bili 冲突。
    2. 什么原因导致:单一 dsh host 每轮保存在 bili 增量水位线以下改写同一历史槽位;快路径按设计跳过这些槽位;采样校验因此永远差一个保存周期,永不收敛,三连升级触发信封冻结。非多实例(单进程、无重启、单槽位签名)。
    3. 影响范围与严重程度:受影响会话的 JSON 信封停止更新(5 个冻结);在线压缩/前缀缓存不受影响(实测 97% 命中);p1 级复合数据丢失窗口仅在 sqlite 同时降级时出现(SQLite unified storage degraded to legacy-only (bili v0.1.205, node v24.22.1, win32-x64) #4614 实例)。当前表现 p2:可用但有明确异常。
    4. 怎么修复的:本轮未改码——对症修复 PR [PR] fix(storage): add field names to drift diagnostics + disable incremental fast path during drift latch (#5677) | fix(storage): drift 诊断补字段名 + 漂移锁存期间停用增量快速路径 (#5677) #5679 已在途待合;是否进一步调整「升级时的冻结语义」属 SQLite unified storage degraded to legacy-only (bili v0.1.205, node v24.22.1, win32-x64) #4614 遗留选项 1/2/3,待 owner 拍板(见下一条 🔶 评论)。
    5. 是否有回归问题:本轮无代码改动,不涉及。
    6. 是否破坏缓存:前缀缓存不受影响(冻结后实测 97% 命中);问题在存储副本面,不在缓存面。
    7. 是否改了设计方向:否;快路径 tradeoff(影子存储(默认开启)每次落盘把整个会话重新序列化+哈希,大会话明显变卡;jsonWriter=off 时连防抖合并都没了 #3133)保持不变,[PR] fix(storage): add field names to drift diagnostics + disable incremental fast path during drift latch (#5677) | fix(storage): drift 诊断补字段名 + 漂移锁存期间停用增量快速路径 (#5677) #5679 仅在锁存期收紧信任边界(到干净样本为止走全量),方向不变。
    8. 是否引入新配置:无。

    判定:分析完成,本轮不改码;冲突问题本身已回答(filesnap 删减类不冲突;机器上实际发生的是已知 #4614-B 类,修复 PR #5679 在途)。是否调整冻结语义待拍板,细节在下一条 🔶 评论。

  2. ranxianglei commented on Nov 8, 2026

    @ranxianglei
    ranxianglei
    on Nov 8, 2026
    OwnerAuthor

    🤖 Powered by ework · qwen3.8-27b

    🔶 需要决策
    (ai: vllm-qwen/qwen3.8-27b)

    背景一句话:单 host「每轮改写水位线以下槽位 → 漂移永不收敛 → JSON 信封冻结」缺陷(#4614 子缺陷 B)在 #4614 关闭时留了选项 1/2/3 待拍板;本线 v0.1.212 现场日志以规模化复现(100 条漂移 / 5 会话冻结 / 跨安装同签名)确认该缺陷在升级后仍然存活;对症的 PR #5679(慢性冻结变有界自愈 + 漂移字段名诊断)已在途待合。

    待决问题:#5679 合并后,是否还要改 bili 的「升级时冻结语义」——即升级(ESCALATED)且无第二实例证据(#4177 检测为负)时,是否继续冻结 JSON 信封写入?

    选项(各带代价):

    八问:

    1. 是什么问题:单一 host 反复改写历史槽位触发 bili 双份副本升级风暴时,现行升级动作(冻结 JSON 信封)是为「漂移=可能多实例」时代设计的假设产物,在单写者场景下制造 p1 级潜在复合数据丢失窗口而非修复正确性。
    2. 什么原因导致:升级动作与根因分布错配——冻结语义来自多实例时期(无单实例守卫:多个 bili 代理进程并存共写 sessions 目录,伴随孤儿 ref、有注册表无 transcript、计数自相矛盾的污染簇 #394/After idling for one hour, the fold override is lost: the client resends byte-for-byte identical content, and the previo | 闲置一小时后折叠覆盖丢失:客户端重发逐字节不变,已折叠的 ~240K token 内容自己回到上下文 #4323),而生产中的漂移主体是单 host 改写(SQLite unified storage degraded to legacy-only (bili v0.1.205, node v24.22.1, win32-x64) #4614-B、本线日志);冻结只隔离症状,不改写方行为不变则下一轮照样发生。
    3. 影响范围与严重程度(按选项):
    4. 怎么修复的(推荐项思路):推荐 A——只在「escalated 且 [PR] storage: durability trio — open-time quick_check + online VACUUM INTO backup + second-process lockfile (#4175) #4177 检测为负」的新状态下加读路由分支,收敛/再准入/水位线逻辑一律不动;与 [PR] fix(storage): add field names to drift diagnostics + disable incremental fast path during drift latch (#5677) | fix(storage): drift 诊断补字段名 + 漂移锁存期间停用增量快速路径 (#5677) #5679 叠加后,冻结事件从永久态变成罕见的短时事件。
    5. 回归风险(按选项):
    6. 是否破坏缓存:三个选项均不触碰缓存/前缀缓存路径(冻结后实测 97% 命中已证明缓存面与该缺陷独立)。
    7. 是否改了设计方向:A 将升级默认从「隔离双份」转向「保证一份新鲜 + 另一份观测」——存储层内语义调整,非架构转向;B/C 方向不变。
    8. 是否引入新配置:无(A/B/C 均为行为/日志变更,不加 env/config key)。

    推荐:先合 #5679(止血 + 拿到字段名诊断),再定 A;不决定的默认行为 = 维持 master 现行为(升级即冻结照旧),本线程留作证据累积,不另动代码。

    A 改冻结语义 B 保持冻结+可见性 C 上报上游
    正确性恢复 立即(JSON 永远新鲜) 无(等干净样本/重启) 无
    p1 潜伏窗口 消除 保留 保留
    改动大小/风险 中小(读路由分支,#4177 门控) 极小 零
    依赖 #4177 检测可靠性 无 外部团队响应
    用户体验 冻结→短暂自愈事件 同现状但可见 同现状
  3. ranxianglei
    added
    bugSomething isn't working
    dsh
    needs-decision
    p2
    scope/storage
    on Nov 8, 2026
  4. ranxianglei
    changed the title [-]dsh-filesnap原始会话删减类是否冲突[/-] [+]Does the original session trimming class in dsh-filesnap cause a conflict? | dsh-filesnap原始会话删减类是否冲突[/+] on Nov 8, 2026

  5. ranxianglei commented on Nov 8, 2026

    @ranxianglei
    ranxianglei
    on Nov 8, 2026
    OwnerAuthor

    通俗易懂讲 是否冲突了 导致了什么 具体咋回事 不要太学术 看不懂

  6. ranxianglei commented on Nov 8, 2026

    @ranxianglei
    ranxianglei
    on Nov 8, 2026
    OwnerAuthor

    🤖 Powered by ework · qwen3.8-27b

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

    一句话:filesnap 的回退功能本身没和 bili 打架;但这台机器上另一个已知毛病被触发了,bili 的存档卡住了。

    冲突了吗?分两层:

    1. filesnap 回退 = 把对话复制一份新的接着聊,旧的贴个「已停用」标签,原文一个字不动。所以它不冲突——我把它源码翻完了确认的。
    2. 但日志里真有一直在坏的事:dsh(外壳程序)每次保存都要改写同一条旧消息。不是 filesnap 干的,是宿主层干的——去年 10 月另一位 Windows 用户(SQLite unified storage degraded to legacy-only (bili v0.1.205, node v24.22.1, win32-x64) #4614)撞过一模一样的,连那条消息的内容都一样。那条消息是 dsh 自己注入的固定样板话,不是用户说的。

    **具体咋回事?**打个比方:bili 给每段对话记两本账(一个 JSON 文件、一个 SQLite 库)。为了省力气,dsh 每次保存时,bili 只核新增的部分、不重查旧账。偏偏 dsh 改的那条旧消息正好在「不重查」的区域里——于是例行全检时永远发现对不上,重新记一遍,dsh 下次又改……永远差一次保存,两本账永远对不齐。连着三次对不齐,bili 触发保险丝:停写 JSON 那本账,免得越差越远。

    导致了什么?

    • 表面:三天 100 条报错,5 个会话的 JSON 账本停止更新。
    • 实际:聊天照常能用,压缩、缓存全部正常(实测命中 97%),进程也没死——这份「崩溃日志」其实不是崩溃,结尾是正常的退出。
    • 真正的隐患:如果冻结期间 SQLite 那边也坏了,两本账都会缺冻结之后的内容。这个组合之前真的发生过(SQLite unified storage degraded to legacy-only (bili v0.1.205, node v24.22.1, win32-x64) #4614),丢过约 5 小时数据。这次 SQLite 没坏,所以没实损。

    **咋修?**修复 PR 已经在路上(#5679):对不上的会话暂时改成「每轮全量记账」,几轮内自动对齐恢复,不再永久卡死;同时日志会直接告诉我们是哪个字段对不上,方便回头找 dsh 侧到底谁在改。合并发版后用户升级即可。另外上一条 🔶 评论里留了一个待你拍板的问题:那个「停写 JSON」的保险丝以后还保不保留(A/B/C 三个选项),你定。

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

    bugSomething isn't workingdshneeds-decisionp2scope/storage

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions