Skip to content

[PR] fix(resume): inherit timestamp ledger so resumed sessions re-render provider-cached tag bytes - #5609

Merged
ranxianglei merged 26 commits into
masterfrom
2026-11-03_resume-timestamp-ledger-carry
Nov 10, 2026
Merged

ranxianglei merged 26 commits into
masterfrom
2026-11-03_resume-timestamp-ledger-carry

Conversation

@ranxianglei

@ranxianglei ranxianglei commented Nov 3, 2026 •

Copy link
Copy Markdown
Owner

Resume-miss timestamp seeding + v3 adoption gate + fold-boundary discipline (#5608)

What this fixes

A desktop client (dsh) that restarts mints a new session id while resending its full history, optionally with a re-rendered tail line. bili saw "unknown id + full old history" and — depending on how closely the resend matched a tracked chain — either (a) started FRESH and re-minted today's date into every historical message's ledger, (b) adopted the closest chain and re-stamped, or (c) mis-adopted unrelated sessions under equal-depth/truncated shapes (the CI reds that first motivated this work: #3686-class byte-exact replays, stated-counts, preflight family). Every one of those paths changed wire bytes across the whole prefix ⇒ provider cache cliff ⇒ the 681K–760K token rebills reported in #5608 (hit rate 97.9% → single digits).

Layers (each independently pinned)

  1. Ledger ride-over (original v2): seedTimestampsFromParent copies the parent's whole tsStamps ledger (orphaned ids included) so days-old timestamps survive an adoption instead of being re-minted now.
  2. v3 adoption gate: weak adoption only for strictly-deeper prefix-break chains with verified prefix ≥ 0.8 (WEAK_ADOPT_MIN_PREFIX_RATIO); equal-depth and truncated shapes NEVER adopt (restores the Claude 上 resume 导致消息错乱 #1486 stance). Rejection logs name shape + numbers. This is what turned the 7 red e2e suites green and stays green on every CI shard.
  3. Windows hydrate race pin (TESTS ONLY): the miss-seed/gate e2e now awaits hydrate-on-listening before firing phase 2 (run 42070023944: all 11 jobs green).
  4. Fold-boundary display-metadata discipline (# Cache hit collapses to 1–12% for a whole generation, then the very next request returns to 100% — repeated 15× in one day #5608-B/C/D) — owner ruling 「应该彻底治理掉的,不能留尾巴」, closed inline per 「不要立issue,原来的pr改」:

Tests

New: kernel/tests/issue5608-timestamp-tails.test.ts (4 pins); re-pinned S15 (cold load is now a no-op), HTTP fork survival, storage digests, and the miss-seed e2e now asserts the honest-NULL contract. Kernel suite 1580/1580; host battery green; tsc clean both trees; verif-subset-guard incl. negative control.


kernel-change: #5608-B/C/D display-metadata fold-boundary discipline (owner-directed in session; issue #5797 closed per owner instruction 「不要立issue,原来的pr改」)

kernel/ changed in commits kernel: #5608-B/C … (45027bb): types/compress/refs/sync + one new test file, version 0.0.180 → 0.0.181. Owner-directed in session (rulings quoted above); initial issue #5797 closed per instruction, this block is the standing declaration. Guarded-file duties: tests/verif-subset-guard.test.ts green (solver verif-* auto-skip without VERIF_PYTHON/cvc5).

…5608)

A stamp is keyed by raw id (SHA-256 of message identity) and renders into the ACP tag time= attribute — cache-relevant bytes. Two paths dropped the ledger, so the first replay after a resume/fork re-rendered every tagged message differently from what the provider had cached:

- adoption (resume hit / fork receipt): refs, blocks and view latches were carried, tsStamps was never carried (#4313 landed after those carries were written) → time-less tags where the original process rendered time-stamped ones;
- resume-inheritance miss: fresh state + empty ref map made the stamp node mint Date.now() for days-old history (the honesty lie its own doc warns against) → the one-generation 1–12% cache collapse reported in #5608 shapes B/C.

seedTimestampsFromParent copies the parent's ledger into the child (child entries win); inherited values always denote the exact bytes the model saw, replaying the stored first-sight time verbatim = the provider-cached tag bytes. Ids absent from the parent map stay honest NULL. Applied on both paths: applyForkAdoption (hit) and the handle.ts miss branch seeding from the closest tracked chain (miss). No new config/env surface.
@github-actions

github-actions Bot commented Nov 3, 2026 •

Copy link
Copy Markdown
Contributor

📦 Built Package Artifact

Branch: 2026-11-03_resume-timestamp-ledger-carry (201775a)

Latest build — install this exact version

npm install -g billion-context@0.0.8927-pr.5609.aab6725

This exact version is immutable and reproducible. The rolling pr tag tracks the newest test build across all PRs.

Recent builds (commit → version)

commit version build
201775a billion-context@0.0.8927-pr.5609.aab6725 build
4eeb781 billion-context@0.0.8422-pr.5609.e7e11df build
27df6c6 billion-context@0.0.8402-pr.5609.c81b0f1 build
c09a0f8 billion-context@0.0.8395-pr.5609.ca20b8b build
6596443 billion-context@0.0.8388-pr.5609.c06688f build
964ba20 billion-context@0.0.8387-pr.5609.fcc06ad build
6e41fb9 billion-context@0.0.8381-pr.5609.0423fde build
3edf28b billion-context@0.0.8370-pr.5609.fd31172 build
f207183 billion-context@0.0.8366-pr.5609.0400139 build
bb01857 billion-context@0.0.8285-pr.5609.a4bdd66 build

Download artifact

  1. Download the artifact from the Actions run
  2. Extract the tarball and install:
tar xzf billion-context-pr5609.tgz
npm install -g package

Install instructions are refreshed on each push.

@ranxianglei ranxianglei changed the title fix(resume): inherit timestamp ledger so resumed sessions re-render provider-cached tag bytes [PR] fix(resume): inherit timestamp ledger so resumed sessions re-render provider-cached tag bytes Nov 3, 2026
@ranxianglei

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

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

标签: bug / dsh / scope/kernel / p1(缓存命中崩坏致成本爆炸 = p1 缓存泄露类;机制在会话核心逻辑——resume/fork 继承时丢时间戳台账)

查重: 不重复。 在途 PR 中唯一触碰 tsStamps 继承的就是本 PR(#5609);触碰 tsStamps 的其余条目(#5236/#5368)是 #4313 特性本身(已合并),#5597/#5398 是不同机制(DIGEST DRIFT / fold coverage)。同症状家族 #4397、#4144 已在 #5608 线程交叉引用、未关闭,本 PR 只修其中的 resume/fork 台账丢失机制,与它们不构成重复。

版本基线: head = master + 单 commit(无陈旧基线),base d244fff 即当前 master。diff 已拉取通读(3 文件 +164/-1)。

审核进行中:正在独立验证机制主张(tsStamps 持久化链路、loadParent 语义、stamp 节点键控、adoption 是否还有其他绕过路径)+ 本地定向测试 + CI 状态,完成后按结构化八问给完整结论。

@ranxianglei ranxianglei added bug Something isn't working dsh p1 scope/kernel labels Nov 3, 2026
@ranxianglei

Copy link
Copy Markdown
Owner Author

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

APPROVE(review 结论以评论形式给出——本账号即 PR 作者,GitHub 禁止自批自 PR,无法落正式 approve review 事件)。独立审过代码与行为(未照抄 issue/PR 描述)。改动最小、隔离、有测试、无 kernel/ 触碰、无新配置面。已本地定向验证。

八问

  1. 是什么问题:resume/fork 后首轮重放时,ACP tag 的 time= 属性被渲染成「无时间戳」(命中路径)或「当前时刻硬铸」(miss 路径),与原始进程当初发给 provider 的字节不一致 → 前缀缓存整段失效一代(# Cache hit collapses to 1–12% for a whole generation, then the very next request returns to 100% — repeated 15× in one day #5608 B/C 形态,每次 ~0.6–0.8M input tokens 重付)。
  2. 什么原因:stamp 按 raw id(SHA-256 内容寻址)落进 state.tsStamps;feat: Support precise timestamps for each message, allowing the model to recognize which messages are outdated and which | feat: 给每个消息支持精确时间,以让模型认识到什么消息是过期的什么是当前的新的 #4313 晚于既有那批 carry 落地,两个继承入口都漏带这份账本——applyForkAdoption 只带 refs/blocks/latch 不带 tsStamps;miss 分支起新状态 + 空 ref map,stamp 节点对天前的历史 Date.now() 硬铸(正是其 doc 注释警告的 honesty lie)。
  3. 影响范围与严重程度:仅影响开启 compress.timestamps 的会话(feature off 时 tsStamps 恒为 undefined,seed 直接 no-op,字节零变化)。触发条件 = 该会话发生 resume/fork 且走命中或 miss 继承。严重度 = 成本类(一代命中率掉 1–12%),非功能不可用;按 owner 缓存泄露类口径归 p1,现有标签正确。
  4. 怎么修复:新增 seedTimestampsFromParent(child, parent)(父条目让位于子已有条目;内容寻址保证继承值恒等于模型见过的精确字节;缺失 id 保持诚实 NULL),两入口都调用:命中路径挂在 applyForkAdoption(覆盖 anonymous fork / identified resume / derived fork / boot reconcile 全部);miss 路径在 handle.ts resume gate 的 miss 分支从最近链 loadParent(miss.best.sessionId) 取父并 seed,fail 降级回旧 fresh-state(warn log)。
  5. 回归风险:逐条过既有行为——feature off:parent.tsStamps undefined → 返回 0、不落空 map(测试钉住)→ 与 pre-feature 字节一致;refs/blocks 继承逻辑未动;内容寻址杜绝错绑(同 raw id 必同字节);child-wins 优先级正确;不共享引用(新 map 拷贝,测试钉住)。无语义漂移 / fail-fast 变吞错 / 阈值时序漂移。两条相邻测试文件(resume-ref-inheritance / resume-adoption-wires)在本沙箱报 parent must have folded a block (got 0)——我做了 A/B:同一两文件在 master base d244fff(不含本 PR 任何代码)失败签名完全一致(同为 5 fail/2 pass、同测试名),确认是预置环境噪声,非本 PR 回归,与作者 stash-baseline 结论吻合。
  6. 是否破坏缓存:正是要修缓存——把重放字节对齐到 provider 已缓存值。tsStamps 持久化经 mergeState(src/state-hydration.ts:71,字段列表机械派生驱动 kstate 序列化)确认跨重启存活,故 miss 路径在父被逐出/重启后仍生效,不只是内存内有效。
  7. 是否改设计方向:否。沿用 copy-on-fork carry 模式(与 hiddenOrphanRefs / emergencyTruncateLatch / viewLatches 同款整份携带),无新机制。
  8. 是否引入新配置:否。复用既有 compress.timestamps opt-in,无新 env/config/默认值,无 wire-shape 变化。

行为变更披露(旧 → new)

开启 timestamps 的会话,resume/fork 首轮重放的 time= 属性由「无时间戳(命中)/ now 硬铸(miss)」变为「逐字回放父会话存下的 first-sight 时间」。原因即本 PR 目的(恢复前缀缓存命中)。feature off 用户零感知。

验证

  • 本地定向跑 PR 自带 tests/resume-miss-timestamp-seed.test.ts:6/6 pass,断言有牙(整表继承 / child-wins / 无 aliasing / no-op 不落空 map / applyForkAdoption 双方向)。
  • CI 镜像缓存在 head 2716196:30 项 0 failed 0 pending(guard/static 全 success;重矩阵 test/e2e 行显示 skipped,故只主张「无失败/无 pending」,不主张 full-suite green)。

非阻塞观察(不改,留记录)

① miss 路径 handle.ts 那 ~20 行接线没有直接集成测试(被测函数本身已充分覆盖;完整 handleRequest harness 太重,不值得单开)。② seedTimestampsFromParent 整份携带父账本不按 incoming ids 过滤——孤儿条目因内容寻址永远查不到、安全,只是多占点字节,且与本函数其它 latch carry 风格一致。③ miss 日志句在 best 完全不相交的边缘情形略乐观,措辞可接受。以上均非机械小修,不 push。

判定:可合(APPROVE)。

@ranxianglei

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b) review-worker-r1 完成:APPROVE。完整结构化八问结论已发上游 PR #5609 评论(comment id 6603407027);本账号即 PR 作者,GitHub 禁止自批自 PR,故无法落正式 approve review 事件,结论以评论给出。要点:机制独立验证通过(内容寻址杜绝错绑、child-wins、flag-off no-op、tsStamps 经 mergeState 跨重启持久化);本地定向跑自带测试 6/6 pass;A/B 证实相邻两测试文件(resume-ref-inheritance / resume-adoption-wires)parent must have folded a block (got 0) 在 master base d244fff 失败签名完全一致 = 预置环境噪声、非本 PR 回归;CI 镜像缓存 head 2716196 0 failed / 0 pending。无 kernel/ diff、无新配置面。判定:可合。

@ranxianglei

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b) 这条是上面 APPROVE review 从上游 PR #5609 同步回镜像的副本(upstream-sync),不是新问题。审核已收尾、无待办:结论 APPROVE,完整八问见楼上,等 owner 合并决策。本线程不再追加评论。

…5608)

Review follow-up on #5609: handlePluginFork copied every sibling ledger (refs, blocks, latches) but dropped tsStamps, so the first replay after a public ACP fork re-rendered the provider-cached time= attrs from freshly minted now-times - the same one-generation prefix re-bill this PR fixes on the adoption and resume-miss paths. Same symptom, same mechanism, so it lands here rather than as a separate issue.

Also completes the miss-path wiring coverage: an end-to-end two-phase test (persist chain under id A, restart, equal-depth replay under id B) pinning that the closest tracked chain donates its ledger above the MIN_RESUME_PREFIX floor.
@ranxianglei

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

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

审核结论:方向正确、机制独立验证成立;审核中发现并直接修掉了第三条丢失路径(同症状同机制,按政策并入本 PR),已推送标注 commit b6270aba0。CI 正在新 head 上跑(test lanes in_progress),绿了即可合。

审核中我做了什么(不是重做,是补漏)

  1. 发现第三条继承路径同样丢账本:handlePluginFork(公开 ACP fork 回执,插件车道走这条)逐字段搬运了 refs/blocks/各类 latch,唯独没搬 tsStamps——子会话首轮重放时 stamp 节点照样给继承来的历史新铸 now 时间戳,产生与 adoption/miss 两条路完全相同的「一代前缀失效重计费」。同症状+同机制,按连贯修复政策在本 PR 内修掉:seedTimestampsFromParent(child, parent) 整表继承(stamps 按内容哈希寻址,不存在位置过滤的语义,与另两条路共用同一 helper、同一纪律)。
  2. 补了 miss 路径的端到端接线测试(原 6 个测试全是单元级,handle.ts 的接线没有覆盖):两阶段重启模拟——阶段一在 id A 下建链并落盘(会话+affinity 快照),阶段二全新进程态下以 id B 等深重放,断言账本逐值继承且「seeded … from closest chain」日志不沉默。调试中钉死一个非显然约束:语料必须 ≥8 条消息(MIN_RESUME_PREFIX=8,低于地板的诊断不产生 closest candidate,seed 档位根本不可达)——已写进测试注释防止后人缩语料静默废掉该测试。
  3. 复现并确认了作者声明的沙箱既有失败:resume-ref-inheritance(3)+resume-adoption-wires(2)共 5 个失败(parent must have folded a block (got 0)),在我未改动的干净 PR head 上(stash 基线)逐条一致,断言打在父会话折叠阶段、早于本 PR 触碰的任何代码——判定为环境噪音,全量判决以 CI 为准。

结构化八问

  1. 是什么问题:resume/fork 之后的第一轮重放,把每条带标签消息的 time= 属性重新渲染成与 provider 已缓存字节不同的值,前缀缓存恰好失效一代,每个事件全额重计费(# Cache hit collapses to 1–12% for a whole generation, then the very next request returns to 100% — repeated 15× in one day #5608 的 B/C 形状)。
  2. 什么原因导致的:时间戳账本 tsStamps(内容哈希键、渲染进缓存相关字节)在三条继承路径上被丢——adoption 搬运时漏项(feat: Support precise timestamps for each message, allowing the model to recognize which messages are outdated and which | feat: 给每个消息支持精确时间,以让模型认识到什么消息是过期的什么是当前的新的 #4313 晚于那些 carry 落地)、resume-miss 走全新状态让节点给陈旧历史铸 now、公开插件 fork 搬运时漏项(本次审核新发现)。根因是「继承只搬了 refs/blocks 却没搬全部缓存字节级账本」,不是渲染层问题。
  3. 影响范围与严重程度:任何发生 resume/fork 的会话,每次事件后第一代全前缀重计费;# Cache hit collapses to 1–12% for a whole generation, then the very next request returns to 100% — repeated 15× in one day #5608 实测单事件 0.6–0.8M input tokens 重算、加权命中率 97.9%→76.5%。p1 成本爆炸类。
  4. 怎么修复的:单一 helper 整表拷贝父账本到子(child 条目优先、无别名、不物化空表),三条路径统一调用;继承值因内容寻址恒等于模型当时看到的精确字节;miss 路径失败降级回旧行为(warn 日志)。
  5. 是否有回归问题:审过的既有行为逐项——applyForkAdoption 原有各 carry 未动、仅在 markDirty 前追加一项;tsStamps 的全部消费方只有 stream.ts 渲染(只读存储值、从不读墙钟)、内核 stamp 节点(只为未知 id 铸造、从不覆写已有值)、hydration/sync 拷贝——均无「新会话必为空表」的隐含假设;miss 分支为纯新增(原先此处无任何行为),异常被捕获后行为与修复前逐字节相同;无 fail-fast 变吞错、无阈值/时序/输出格式漂移。本地 5 个失败已证实与本 diff 无关(见上)。CI 全量判决进行中。
  6. 是否破坏缓存:不破坏——本 PR 就是修缓存的;未触碰任何失效策略/去重键/游标。
  7. 是否改了设计方向:否。沿用与 ref seeding 完全相同的内容寻址纪律,无新增架构件。
  8. 是否引入新的配置:无。无 env/config/默认值变化;wire 格式不变;无 kernel 改动。

行为变更披露(old → new)

  • 旧:resume/fork 后第一轮重放,标签要么缺原始 time=(adoption/fork 路径)要么带新铸 now 时间(miss 路径)→ 每次 resume/fork 恰好一代全前缀失效,之后恢复稳定。
  • 新:三条路径均继承账本 → 前缀跨 resume/fork 字节稳定;只有真正的新消息获得新时间戳。
  • 已知残留(有意留白,非遗漏):miss 分支的 loadParent 磁盘读失败降级路径(3 行 catch,结果=修复前旧行为)无故障注入测试——注入需复制整套两阶段 harness,代价不成比例;如你认为需要钉住,说一声我补。

遗留事项(不在本 PR 范围)

收工判定:可合(等 b6270aba0 的 CI test lanes 转绿;我这边定向验证全绿:resume-miss-timestamp-seed 7/7、plugin-fork 57/57、fork-adoption-plan + resume-inheritance-miss-diagnostics 通过、typecheck clean)。

ci-check added 3 commits November 3, 2026 21:10
…er-cached prefix (#5608)

A resume-inheritance MISS started FRESH state: new ref numbers, minted-now (or absent) tag times, and RAW ranges where the old process sent FOLDED carriers. Every tagged byte flipped vs the provider-cached prefix, so the whole history re-billed for one generation (the 1-12% one-generation cache collapse in #5608).

The miss path now adopts from the CLOSEST tracked chain instead of starting bare (maybeAdoptResume with blocksEnabled: true). Refs/blocks/latches/timestamps are all raw-id (content-hash) keyed, so every carried value denotes the exact bytes the model saw; set-semantics adoption self-defends against the deep divergence that broke the byte-exact gate (a block whose sources were mutated is simply straddled). Honest ceiling: the true common prefix.

applyForkAdoption also carries the tsStamps ledger (#4313 landed after the other carries were written, so adoption dropped it): without it the first replay rendered time-less tags where the original rendered time-stamped ones. maybeAdoptResume gains an optional via phrasing so the weak path logs its relationship honestly; strong-path log output stays byte-identical (pinned by a regression test).
…nudge state, #5555 copy sweep)

master d244fff is born-red on these four goldens (#5415 added persisted nudge state fields without regenerating); the sentinel converged the regen onto origin/ci-fixes 4809a83 per the CI-coordination policy (#4599). This head carried the stale copies verbatim, so every shard failed the same four assertions. Adopting the sentinel-converged files instead of regenerating keeps one source of truth. Verified under the full CI preload chain: golden-storage-render 5/5 green here (was 1/5).
Under the CI preload chain (tests/preload-test-env.mjs) the suite-wide BILI_MESSAGE_TIMESTAMPS=0 pin suppresses stamp minting entirely, so the two #5608 tests that prove ledger inheritance fail their stamp preconditions (and their ledger equality would be tautological without them). Defeat the pin per test with save/restore, mirroring tests/message-timestamps-default-on.test.ts:45. Verified under the full CI preload chain: both files green together with golden-storage-render (71/71), typecheck clean.
@ranxianglei

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

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

状态更新(分支移动 + 两处残留修复):

分支状态:审核期间分支落了 owner 侧新提交 6d40dd1——miss 路径从「只 seed 时间戳」升级为从最近链做完整弱采纳(refs/blocks/latches/stamps 全部按内容寻址值继承;强路径日志保持不变并有回归钉)。评估:方向成立且严格强于 seed-only(连 ref 编号与折叠载体一并恢复),对深度分歧自防御(源被改写的块直接跳过不采纳);我此前的 b6270ab 第三路修复仍在历史中。

新 head 上的两处残留问题(本地复现并已修):

  1. 仍带陈旧 storage-render golden ×4(= 继承性 master 红:In 0.1.210, sessions with frequent interruptions barely trigger compression reminders — tokens accumulate to 330k before | 中断频繁的会话在 0.1.210 里压缩提醒几乎不触发,积到 33 万 token 才压一次 #5415 加了 nudge state 字段但 golden 未再生,与 [PR] fix(#5595): keep fork children sendable when raw-history rebuild emits empty tool-call arguments #5602/[PR] fix: preserve CLI help and version before subcommand dispatch #5607 同签名)→ 采用 ci-fixes(4809a83) 收敛的再生版(c79311fc9);
  2. 两个新增测试缺对套件环境 BILI_MESSAGE_TIMESTAMPS=0 pin 的 defeat → CI preload 链下根本不 mint stamp,前置断言必挂、相等断言退化为恒真 → 按 message-timestamps-default-on 先例逐测试 save/restore(c73b1af68)。

本地按完整 CI preload 链验证:golden-storage-render + resume-miss-timestamp-seed + plugin-fork 共 71/71 绿,typecheck 干净。已推 c73b1af。

更正说明:我先前在 #4599 报告的「新 head sha=d658f5b7c」现已不在分支上(GitHub API 422 No commit found);本次推送基于当前 tip 6d40dd1 重新落地了同样两个修复。

结论不变:可合,等 c73b1af 的 CI 重跑转绿。

# Conflicts:
#	tests/golden/storage-render/anthropic.json
#	tests/golden/storage-render/chat.json
#	tests/golden/storage-render/google.json
#	tests/golden/storage-render/responses.json
@ranxianglei

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

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

本轮已完成(机械部分):PR 与 master 的合并冲突已解决并推送——merge origin/master(9dc4c94,分支落后 64 个提交)进 PR 分支,唯一冲突是 4 个 tests/golden/storage-render/*.json,全部取 master 侧(已收敛 #5555 copy sweep + #5559 kernel batch 两批再生成的版本)。新 head sha=2d3230a83,已推送,dirty 状态应随下次镜像轮询转干净,CI 将在新 head 上重跑。本地验证:typecheck 干净;PR 自有测试(plugin-fork + resume-miss-timestamp-seed)66/66 绿;golden-storage-render 绿。needs-decision 标签已打。

红 CI 根因(不是继承性失败,是 PR 自身提交的行为变更):本地定向复现 + 二分钉死——基座 d244fff 与 b6270ab 上涉事测试全绿,owner 提交 6d40dd1(resume-inheritance MISS 从「只 seed 时间戳」升级为「从最近链全量弱采纳 refs+blocks」)一上,同一批测试立刻红,签名与 CI 完全一致;合并 master 后失败集不变(纯该提交贡献,非 master 漂移、非负载抖动)。受影响:9 个 e2e 回归文件、13 条断言(issue1993×3、ccr-v2、fix-781-summary-images、issue1195-overflow-refold×2、issue2733、preflight-nonstream-400-probe、preflight-stream-summary-config×2、cache-friendly-plugin #3769、wire-exit-matrix error-delivery)。机理一致:弱采纳把旧进程的 blocks/refs 恢复回新会话后,原本「fresh start → 重新 fold / 触发 preflight 摘要 / fail-fast 502」的路径变成了「已覆盖 no-op / 跳过摘要直接 200」。其中多数断言像是钉死了旧行为(新行为正是 #5608 想要的缓存前缀恢复),但个别(wire-exit-matrix 期望 200 实得 429、#1993 的 fail-fast 错误契约)可能是门过宽的真实信号——逐条裁定超出机械修复范围。

选项:

在决策落地前我停手不动此 PR(自动修复车道 attempt 1/3,剩余尝试留给决策后的执行)。备注:#4599(CI 总控)的镜像线程号在本环境解析不到,按身份规则不猜编号,状态行未发,特此说明。


结构化八问(本轮)

  1. 是什么问题:两个 blocker——①分支落后 master 64 提交致合并冲突(dirty);②11 个 test shard 全红(13 条断言失败)。
  2. 什么原因导致的:①master 前进([PR] fix(kernel): false-advertising batch — real schemas, aligned prompts, '..' separators (#5555) #5559 kernel batch、golden 再生等)而分支停在 d244fff;②owner 提交 6d40dd1 改变 resume-miss 行为(fresh start → 全量弱采纳),9 个 e2e 文件钉死的旧语义被打破——二分证据:d244ffff2 绿 / b6270ab 绿 / 6d40dd1 红,签名与 CI 逐条一致。
  3. 影响范围与严重程度:测试面 9 文件 13 断言;生产面 = # Cache hit collapses to 1–12% for a whole generation, then the very next request returns to 100% — repeated 15× in one day #5608 预期行为本身(resume miss 后恢复 provider-cached 前缀),非崩溃/数据丢失,但 ≥3 条用户可见错误契约(fail-fast 502、摘要拒绝可见性)形状变化,需 owner 确认是「期望漂移」还是「过火」。
  4. 怎么修复的:冲突机械解决(merge master,golden 取 master 侧收敛版);红 CI 完成根因定位与复现,升级为决策(A/B/C,推荐 A)。
  5. 是否有回归问题:本轮 merge 自身无新增破坏——合并前后失败集逐条相同(全是 6d40dd1 贡献);typecheck/PR 自有测试/golden-storage-render 均绿。既有行为中「resume-miss 后 fresh start」被有意变更(6d40dd1,owner 推送),披露如下:旧值=只继承时间戳账本,新值=refs+blocks+latches+时间戳全量弱采纳。
  6. 是否破坏缓存:不涉及(本轮未动运行时逻辑;弱采纳的设计目标恰是保缓存)。
  7. 是否改了设计方向:不涉及(方向为 owner 已推送内容;门宽与测试基线待决策)。
  8. 是否引入了新的配置:无。

判定:冲突已清、根因已钉、球在决策区——拍板 A/B/C 后我继续收尾。

@ranxianglei

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

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

新 head(2d3230a)CI 重跑核查完毕:红项与上轮完全同源,无新增破坏,决策请求(floor 16)仍然有效、仍在等拍板。

本轮做了什么:

  1. 拉了新 run(41666118938)的失败清单并与上轮逐条比对:11 个 shard 全红的签名与上轮一致。其中 2 条是「换 shard」造成的表面差异——merge master 带入了新测试文件,shard 重新配平后 preflight-google-summary(#829) 与 search-plan-aware(planAware off) 落到了 ubuntu22-s2,而 issue2733/#2494 移去了别的 shard(不是新增失败)。
  2. 对这两条补做了本地定向验证(防止是 merge 引入的新问题):合并 head 上两文件 2 fail(签名与 CI 一致:a summary was requested / lexical winner returned);回到弱采纳之前的 b6270ab 同两文件 15/15 绿。结论:同属 6d40dd1(weak adoption on resume-miss)家族,机理相同——采纳恢复的 blocks/refs 让「应当发生的摘要调用/lexical 返回」被「已覆盖」短路。
  3. 更正一处口径:受影响面比上轮单 shard 估算略大——全局至少 11 个 e2e 文件(原 9 个 + preflight-google-summary + search-plan-aware),失败总数随 shard 配平在每 shard ~13 条浮动,但文件全集以上述 11 个为准。根因、选项(A/B/C)、推荐(A,默认)不变,全部见 floor 16,不重复贴。

结构化七问(本轮)

  1. 是什么问题:merged head 上 11 个 test shard 仍全红——同一批断言。
  2. 什么原因:owner 提交 6d40dd1 的 resume-miss 弱采纳改变了 fresh-start 语义;本轮核查排除了「merge master 引入新问题」的可能(两条换 shard 的新面孔已 A/B 钉死同源)。
  3. 影响范围与严重程度:11 个 e2e 回归文件的旧语义基线;生产行为 = # Cache hit collapses to 1–12% for a whole generation, then the very next request returns to 100% — repeated 15× in one day #5608 预期方向本身,是否过火待 owner 裁定(见 floor 16 选项 B 的风险项)。
  4. 怎么处理的:只做了验证与比对,未动分支——机械修复空间为零,球在决策区。
  5. 是否有回归:merge 本身无新增破坏(失败集 = 6d40dd1 贡献,合并前后逐条可比);typecheck/PR 自有测试/golden 上轮已验。
  6. 是否破坏缓存:不涉及。
  7. 判定:停手等 A/B/C 拍板(needs-decision 标签已在),拍板后我按选定路线一次收尾。

@ranxianglei

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

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

本轮为重复触发,无新动作:本次通知指向的 run(41666118938)与上一轮(floor 19 已核查)是同一 run、同一批 job、同一 head(2d3230a),失败集已在上一轮逐条比对并本地 A/B 钉死——全部同源 owner 提交 6d40dd1(resume-miss 弱采纳 vs 11 个 e2e 文件的旧语义基线)。线程里仍无 A/B/C 拍板,机械修复空间为零,未重复拉日志、未动分支。

七问(本轮)

  1. 是什么问题:同一红 CI 再次触发(同 run 同 head),非新故障。
  2. 什么原因:根因不变——6d40dd1b6 行为变更打破既有回归基线(详见 floor 16/19)。
  3. 影响范围与严重程度:不变:11 个 e2e 文件;生产行为即 # Cache hit collapses to 1–12% for a whole generation, then the very next request returns to 100% — repeated 15× in one day #5608 预期方向,过火与否待裁定。
  4. 怎么处理的:核对触发参数(run/job/sha 全同)后确认无需重复验证,停手。
  5. 是否有回归:无新增;分支自 2d3230a 起零改动。
  6. 是否破坏缓存:不涉及。
  7. 判定:继续停手等 floor 16 的 A/B/C 拍板(needs-decision 标签在);拍板后立即按选定路线一次收尾。若此重复触发还会再响,建议平台侧对「needs-decision 已挂起」的 PR 抑制 auto-fix 重派。

@ranxianglei

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

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

新 head(91be1cc,「sync master 预合并重跑」——他人推送,线程内未见 A/B/C 拍板记录)核查完毕:失败集与既有家族完全同源,master 同步未引入新破坏。决策请求(floor 16)继续有效。

本轮做了什么:

  1. 比对新 run(41851266114)失败清单:ubuntu22-s2 上 14 条,其中 13 条与上轮逐条一致;唯一「多出来」的一条是 #781/#2607 (Anthropic): archivable image folds(上轮该 shard 只见同文件的 OpenAI 变体)。
  2. 对这条做了本地 A/B 排除「master 同步引入回归」:在旧 head 2d3230a 与新 head 91be1cc 上各跑 tests/fix-781-summary-images.test.ts——两个 head 都是 2 fail/12 pass,签名一致(placeholder reaches the summary 前置断言挂掉,机理=弱采纳恢复的块短路了本应发生的摘要调用)。结论:Anthropic 变体一直在家族内,只是上轮落在别的 shard 没被我看到的那份日志覆盖,非新增。
  3. 未动分支(91be1cc 为外部推送的 master 同步,本地分支已对齐到它以便验证,无本地改动、无推送)。

七问(本轮)

  1. 是什么问题:master 同步后的预合并重跑仍全红——同一批断言。
  2. 什么原因:根因不变(owner 提交 6d40dd1 弱采纳 vs 11 个 e2e 文件旧语义基线);本轮额外排除了 [Bug] Config save rejects valid mitm:// provider lanes as "invalid recipe on named provider" | 整文件保存把 mitm:// 路由误判为命名配方 #5620 media-fold kernel 变更等 master 新提交的嫌疑(A/B 钉死)。
  3. 影响范围与严重程度:不变:11 个文件;生产行为即 # Cache hit collapses to 1–12% for a whole generation, then the very next request returns to 100% — repeated 15× in one day #5608 预期方向,过火与否待裁定。
  4. 怎么处理的:日志比对 + 单文件双 head 本地 A/B,确认无新根因后停手。
  5. 是否有回归:无新增;91be1cc42 相对 2d3230a 的差异(master 同步)未改变失败集。
  6. 是否破坏缓存:不涉及。
  7. 判定:继续停手等 floor 16 的 A/B/C 拍板(needs-decision 标签在)。注:若「pre-merge CI re-run」是准备合并的信号,当前红项不随 master 同步消失,合并前仍需先定 A/B/C——推荐 A(默认)。

…5608)

v2's miss path adopted the closest tracked chain unconditionally once
byte-exact matching failed. Content similarity alone cannot PROVE same-
conversation identity, and three measured misfire shapes ship exactly that
(false-positive cross-session adoptions inside one proxy process):

  equal-depth  two unrelated sessions resending the SAME conversation
               bytes under new ids — #3686 replayed a 15K-token fixture
               verbatim across lanes and the foreign fold block landed on
               the declared-pi session ('no fold may land' broke)
  truncated    a session resending a SHORTER subview of another session's
               live chain
  head break   near-duplicate boilerplate conversations diverging at cell
               0-8 of short chains (#3450/#3645/preflight families saw
               inherited token budgets flip fail-fast paths)

v3 gates the weak rung to the ONLY shape identity can be argued for:
strictly-deeper prefix-break continuations whose verified common prefix
reaches >= WEAK_ADOPT_MIN_PREFIX_RATIO (0.8) of the parent chain depth.
The floor sits just below the lowest production telemetry reading in
#5608's maintainer comments (dsh desktop restart LCP floor 632/760 = 0.83)
and far above every measured CI misfire (<= 0.67). Equal-depth replays
never adopt weakly again, restoring the #1486 stance v2 overrode without
proof; truncated subviews likewise start fresh. Every rejection logs its
shape and numbers; honest-log discipline unchanged. fork-adoption.ts and
plugin.ts are untouched (bisect proved them innocent of the red CI).
…and pin the v3 adoption gate (#5608)

The old e2e fixture was an equal-depth byte-exact replay — precisely the
shape v3 now rejects by design, so it could not coexist with the fix. It
now sends what production actually does (telemetry in #5608): the same
history with recent-tail drift plus one appended turn under a new id,
which defeats byte-exact matching and lands on the weak rung. Assertions
now pin the actual bug contract: days-old stamp values ride over UNCHANGED
(the seed copies the whole parent ledger), only the fresh/drifted turns are
minted live, and the adoption stays logged, not silent.

New sibling test pins the gate itself: an equal-depth replay and a
truncated subview of a tracked chain must both start FRESH with their OWN
ledgers and name their rejection reason — the two shapes whose adoption
was red on CI.
@ranxianglei

Copy link
Copy Markdown
Owner Author

v3: 弱收养加身份门(修上一轮全红)

上一版(v2,commit 6d40dd1)把 red CI 带回来了,根因不是某个测试坏了,而是 miss 路径拿到“最近的链”就无条件收养——它没有身份判断。字节精确匹配本身没问题;问题在它失效之后没有任何兜底证明。本地探针实测出三种误伤形状(同一代理进程内、跨会话的假阳性):

形状 现象 受害者
equal-depth 重放 两个无关会话用新 id 发同一份内容,上一个会话刚折的块被搬到新会话上 #3686 “declared pi above 0.9 bar must not fold” 被击穿(fixture 就是 15K token 逐字节重放)
truncated 子集 一个会话重发另一个会话活跃链的前 N-1 条 preflight-hold / preflight-empty-summary / #3450 / #3645(继承 token 预算后 fail-fast 判定翻转)
head-break 相似链 CI fixture 之间共享样板,头部就分叉(实测 0%~67% 前缀) fix-1001 ref 编号位移等

生产真实形状(本 issue 维护者评论里的 dsh 桌面重启遥测)只有一种:严格更深 + 只在近期尾部漂移,已验证 LCP 下限 632/760 ≈ 0.83。这跟三种误伤形状之间有干净的间隙。

改动(2 commit:2735930 core,814252b tests-only)

src/server/handle.ts — weak 路径新增准入门 WEAK_ADOPT_MIN_PREFIX_RATIO = 0.8:

  • 只有 prefix-break(严格更深)且 verifiedPrefix/chainDepth ≥ 0.8 才弱收养;
  • equal-depth 永不弱收养(恢复 Claude 上 resume 导致消息错乱 #1486 的设计立场——内容无法区分“重启重放”和“同一内容的另一个会话”,Claude 上 resume 导致消息错乱 #1486 当年就是这么拒绝的,v2 没给证据就推翻了这个立场);
  • truncated 不弱收养(更短的续发不是延续);
  • 每次拒绝都打 info 日志写明形状和数字,honest-log 不变。

fork-adoption.ts / plugin.ts 不动——bisect 已证明它们与红 CI 无关(只还原 handle.ts 一个文件就能复现全部失败)。

测试

  • 原 e2e fixture 是等深重放,恰好是 v3 按设计要拒的形状,改成生产真实形状(尾部漂移+追加新轮次),断言改为真正钉 bug 合约:天龄 stamp 原值带走(seed 整表拷贝)、只有新轮次当场 mint、收养有日志不落静默。
  • 新增反向回归测试:等深重放 + 截断子集两条都必须 FRESH 且各自说明拒绝理由。
  • 本地矩阵:受影响 7 个套件全绿(35/35)+ seed 文件 10/10 + tsc 通过。

CI 结果以本评论后的 run 为准。

@ranxianglei

Copy link
Copy Markdown
Owner Author

CI 复跑分析:v3 已修掉全部 7 个误伤套件,剩余红全是 master 自身带的

新 run 41993806624(head 814252b)仍有 10 个矩阵 job 红,但不是本 PR 的代码——干净 master(0aace2f)自己的最新 CI run 41986289521 14 个 job 全红。逐 shard 对比失败测试名集合(sharding 按文件名,同索引 shard 可直接比):

shard 本分支 (814252b) 干净 master (0aace2f)
test (ubuntu-latest, 22, 2) session-level: the dsh lane stamps the guard… 完全相同(diff exit 0)
test (ubuntu-latest, 24, 1) issue #2817 regression … cross-wire switch …, dsh lane stamps the guard 这两个 + #5418 A/B byte-equality + residency band(⊇ 本分支)

master 侧的失败家族还包括 #1993×3、#2777、cache-friendly #3769、e2e #1195 C、e2e #2133×2、e2e #781×2、planAware search、CCR v2、preflight #829、error-delivery SSE 等(老 run 各 shard 里可见)。

关键验证:本分支 run 的全部日志里,上一版(v2)带红的 7 类签名一个都不再出现(#3686 “no fold may land”、#3450 stated completion、#3645 fail-fast、fix-1001 ref 计数、preflight-hold/empty-summary)。本地矩阵:受影响 7 套件全绿(35/35)+ resume-miss-timestamp-seed 10/10 + plugin-fork 57/57 + tsc 通过。

结论:v3 的身份门把误伤清零;PR 在 GitHub 上继续显示红是基线问题——需要有人先把 master 的这波红(#2817 / dsh-lane guard / #5418 A/B 等)修绿,之后本 PR 的 CI 才能转绿。建议在单独 issue/PR 处理 master 红,不和本 PR 混。

@ranxianglei

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

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

收到你的「结局冲突」(floor 64)。这条太简短,我不敢替你解读成某个决定——先把刚核实的几处「冲突」摆出来,请你指认指的是哪个、要我做什么:

A. 本线程前后两个相反判定(若「结局」=结论):不是自相矛盾,是跟着范围变的——早期 APPROVE 针对不含内核的旧 head 2716196ba(正文当时写「No kernel change」);PR 后来推进到 27df6c616,diff 实际改了 kernel/(compress/refs/sync/types,#5608-B/C/D),我才改判需 owner 授权。当前有效结论 = 后期这条(需授权)。

B. 分支现在是 mergeable_state: dirty(若「冲突」=合并状态):刚查 GitHub API,PR 与 master 有未解 merge 冲突。要的话我按上游冲突唤醒流程 rebase/merge master 解掉再推——但这是动分支的操作,等你确认再动手。

C. 正文一致性:已核实当前正文已正确带 kernel-change: 声明,旧的「No kernel change」句已不在,正文与 diff 在内核点上不冲突。(小瑕疵:正文版本行写 0.0.180→0.0.181,net diff 实为 0.0.182→0.0.184,早期迭代遗留,review 里已备注。)

在你明确前我不动分支、不擅自下结论。请告诉我 A / B / C 哪个(或其它)、以及期望动作。

…→0.0.185 (max+1: branch #5608-B/C/D at 0.0.184 + master #5789 unit-projection at 0.0.183)
@ranxianglei

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

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

冲突已解决并推送(4eeb781):把 master(d640d0d)merge 进 PR 分支,唯一文本冲突 = acp-kernel 版本行(三处文件),按 max+1 裁定为 0.0.185。镜像 mergeable_state 会随轮询从 dirty 自动转干净。

七问:

  1. 是什么问题:上一轮全绿 head 27df6c616 之后 master 又前进了 22 个提交([PR] fix(release): direct-path release notes have always been the placeholder "- initial release" — the newly created tag sha | fix(release): direct-path 发布说明一直是占位符 "- initial release"——新打的 tag 遮蔽了 git describe #5378 release-notes-describe-exclude、[PR] fix(plugin-fork): lift the thinking hard gate — thinking sessions can fork (#4266) #4900 fork-thinking-gate、[PR] fix(dsh): DSH Remote long sessions skip compression due to stale fetch-chain re-entry state #5616 dsh-remote-compression-bypass、Reaching out to the author — a plugin bug is throwing errors and causing the context to balloon rapidly. | 求助作者,插件bug报错导致上下文急速增加 #5789 kernel unit-projection tier2 ladder 等),分支落后 base 22 个提交 → GitHub 判 dirty(merge conflict),阻塞合并。
  2. 怎么修的:用 merge commit 把 origin/master 合进 PR 分支(不 rebase,保留 owner # Cache hit collapses to 1–12% for a whole generation, then the very next request returns to 100% — repeated 15× in one day #5608-B/C/D 提交的完整历史——与 f207183 轮同一做法)。文本冲突仅三处、全部是 acp-kernel 版本行(kernel/package.json + kernel/package-lock.json + 根 package-lock.json):分支侧 0.0.184(携带 # Cache hit collapses to 1–12% for a whole generation, then the very next request returns to 100% — repeated 15× in one day #5608-B/C/D 内核改动)vs master 侧 0.0.183(携带 Reaching out to the author — a plugin bug is throwing errors and causing the context to balloon rapidly. | 求助作者,插件bug报错导致上下文急速增加 #5789 unit-projection 改动),双方都从基线 0.0.182 各自提升 → 按 max+1 裁定 0.0.185:合并后的树同时携带两边各自未发布的内核改动集合,0.0.184/0.0.183 都不对应这个组合集。其余重叠文件 git 全部自动干净合并,零手工介入。
  3. 验证了什么:① 对称父 diff 核对——merge 结果 vs master 父 = 恰好等于 PR 自身改动(plugin.ts +15/-1、plugin-fork.test.ts +28/-3);vs 分支父 = 恰好等于 master 改动(plugin.ts +60/-4、plugin-fork.test.ts +12/-1),两侧 hunk 零丢失、零污染;② typecheck clean(含 kernel/pi-subagents 构建);③ 定向测试而非本地全量:内核侧 17/17 绿(issue5608-timestamp-tails / issue5789-tier2-merge-ladder / issue4484-merge-coverage / issue3236-recommend-apply-consistency,覆盖双方新增/修改的全部内核测试文件);宿主侧 63/63 绿(plugin-fork——唯一双方同改的文件——+ msgid-lane-flow)+ PR 核心 e2e resume-miss-timestamp-seed 10/10 绿。全量矩阵判定交给推送后的 CI 重跑。
  4. 行为变更:产品代码零改动——仅一个 merge commit + 一次版本调和(PR head 处 acp-kernel 显示 0.0.185,合入后随 master 带走,属预期)。语义交互点已核:master 的 Zero-Inheritance Session Cloning: Unified Fix for Eight Independent Defects in the Fork Adoption Chain (Next Release Tar | 会话克隆零继承:fork 收养链上八类独立缺陷统一修复(下版目标) #4266 fork 身份 hash 改造(thinking 签名入 digest、thinkingTokens 降为存在性比较)与本 PR 的 timestamp ledger carry 正交并行——前者改「漂移怎么判」,后者改「重放哪些字节」,交汇面(handlePluginFork fork 路径 + plugin-fork e2e)本地验证绿。
  5. 回归风险:自动合并文件逐个过语义冲突——src/plugin.ts:master 的 hunk 集中在 fork 身份/快照视图区(:1046–1320),PR 的 hunk 在 import 行(:75)与 handlePluginFork carry 块(:1654),零重叠;tests/plugin-fork.test.ts 同样不重叠(master :737 taxonomy pin vs PR :298 ledger-carry 测试 + :994 冷加载钉)。内核侧 master 的 unit-projection 改动与本 PR 的 compress/refs/sync/types 改动分属不同文件,经内核套件 + [Bug] recommend/apply 对同一区间的 turn-integrity 判定永久不一致:acp_status 反复推荐的区间被 apply 侧整段拒绝(0.1.196,Range would split N turn(s) at the protected-zone boundary) #3236 一致性测试验证。未见语义破坏,最终判定以新矩阵为准。
  6. 门禁与决策:未触发任何新授权门禁;PR 正文 kernel-change 声明原样保留(本次 merge 未新增内核 diff,仅版本行调和)。既有 🔶 待决项(owner 授权内核变更合入)仍然有效、未重复发——本轮是纯机械冲突处理。
  7. 判定:冲突处置完毕,新 head 4eeb781f2 已推送,等新 CI 全矩阵绿(镜像缓存此刻仍显示旧 sha 的全绿快照 {total:30, failed:0},轮询 ~1 分钟刷新,新 run 随后起);若仍有红我按车道继续接。合并权与内核变更授权仍在 owner 手里。

@ranxianglei

Copy link
Copy Markdown
Owner Author

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

FINDINGS-ONLY REVIEW(head 4eeb781f2)— 不批准(需 owner 人工授权)。本条针对新 head;实质结论延续我上一轮(对 27df6c616)的 findings-only review,因为本轮的唯一变更是一次干净的 master 同步合并,特性代码本身一字未改。

本轮新增:master 同步合并的正确性(重点核过)

head 4eeb781f2 = 上一轮我审过的 27df6c616(第一父)+ master d640d0d06(第二父)的 merge commit,解决上一轮遗留的 dirty 冲突。逐项核实:

八问(特性未变,答案稳定;逐机制深析见上一轮 review)

  1. 是什么问题:resume/fork/restart 后首轮重放重铸 tag 的 time= 字节(无时间戳/now 硬铸/冷加载重编号),与 provider 已缓存前缀不一致 → 整段前缀缓存失效一代(# Cache hit collapses to 1–12% for a whole generation, then the very next request returns to 100% — repeated 15× in one day #5608 报告 681K–760K token 重付)。一次治理 A/B/C 三成因 + v2 无条件 weak-adoption 误采。
  2. 什么原因:feat: Support precise timestamps for each message, allowing the model to recognize which messages are outdated and which | feat: 给每个消息支持精确时间,以让模型认识到什么消息是过期的什么是当前的新的 #4313(timestamps)晚于既有继承 carry 落地,tsStamps 从未被 carry;冷加载每次重启对全部 ref 重编号(After model switch / client-side history rewrite, all message identities (content hashes) are replaced: ACP numbers re-m | 切模型/客户端重写历史后,消息身份(内容哈希)全部更换:acp 编号重铸、折叠覆盖大规模重挂、死 ref、churn 区临时膨胀重折 #4316)本身即一次前缀改写;v2 miss 无条件采纳最近链在 equal-depth/truncated/head-break 三形状上误采。
  3. 影响范围与严重程度:仅开启 compress.timestamps 的会话(off 时 tsStamps/highWater 恒 undefined,全 no-op,字节零变化);触发=该会话 resume/fork/restart 或中途开 flag。成本类(一代命中率掉 1–12%),非功能不可用;按缓存泄露口径 p1(标签已正确)。
  4. 怎么修复(机制层,同上一轮):v2 ledger ride-over(seedTimestampsFromParent,raw-id 内容寻址 child-wins)+ v3 adoption gate(WEAK_ADOPT_MIN_PREFIX_RATIO=0.8,仅严格更深的 prefix-break 链且 verifiedPrefix/chainDepth≥0.8 才 weak-adopt)+ # Cache hit collapses to 1–12% for a whole generation, then the very next request returns to 100% — repeated 15× in one day #5608-B honest-NULL arm(suppressMintingOnce 一次性)+ # Cache hit collapses to 1–12% for a whole generation, then the very next request returns to 100% — repeated 15× in one day #5608-C high-water mark(time= 仅对 ref seat > mark 的消息渲染)+ # Cache hit collapses to 1–12% for a whole generation, then the very next request returns to 100% — repeated 15× in one day #5608-D deferred alignment(冷加载不动字节,fold 提交后置 pendingLedgerAlign、下次 save 才对齐)。
  5. 回归风险:feature off 全 no-op 字节不变;refs/blocks/latch 继承未动(新增并列 carry);内容寻址杜绝错绑、child-wins、map 拷贝不共享引用;# Cache hit collapses to 1–12% for a whole generation, then the very next request returns to 100% — repeated 15× in one day #5608-D 最大回归面已被 S15 双向重钉(冷加载保 legacy ref / fold+save 单趟对齐 marker 恰消费一次 / 二次 save·cold-load no-op);# Cache hit collapses to 1–12% for a whole generation, then the very next request returns to 100% — repeated 15× in one day #5608-C×fold/remint 交互由 refs.ts 对齐抬 mark 兜住假 cliff(kernel test C#3 钉);key-free 纪律(两新字段 legacy 恒不物化键)。无 fail-fast 变吞错、无阈值/时序静默漂移。本轮 merge 未引入任何新的回归面(仅叠加 master 已测改动)。
  6. 是否破坏缓存:正是要修缓存——把重放/折叠字节对齐到 provider 已缓存值;tsStamps/highWater 经 mergeState 持久化跨重启存活。
  7. 是否改设计方向:否。沿用 copy-on-fork carry + 既有 adoption 框架加一道 verified-prefix 门;无新架构。
  8. 是否引入新配置:否。复用既有 compress.timestamps opt-in;无新 env/config/默认值;wire-shape 不变。

行为变更披露(旧值 → 新值,同上一轮)

  • 开启 timestamps 的会话,resume/fork 首轮重放 time= 由「无时间戳(命中)/ now 硬铸(miss)」→「逐字回放父存下的 first-sight 时间」。
  • 中途开 flag / off→on 升级:旧 ref 保持无属性直到自身 edit/fold 重铸(零前缀字节)。
  • 冷加载:不再每次重启重编号,推迟到下次 fold(从不 fold 的会话 citation-space 停留 legacy counter ref,功能无损)。
  • feature off 用户零感知。

测试 & CI

  • 测试有效性:新内核测试 kernel/tests/issue5608-timestamp-tails.test.ts 4 例(B/C 两 cliff 有牙)+ S15 双向重钉覆盖 # Cache hit collapses to 1–12% for a whole generation, then the very next request returns to 100% — repeated 15× in one day #5608-D 最大回归面——详见上一轮,未变。
  • CI(镜像缓存 @ 4eeb781f2,fetched 02:47Z){total:30, failed:0, pending:8}:static-gates/mysql-contract/gate 及已跑完的 test shard 全 success,8 个 test shard 仍在跑(未失败)。上一 head 27df6c616 曾全绿 {failed:0,pending:0},本轮增量仅为干净的 master 合并(其改动已在 master 侧通过),预期落绿;但按纪律我只主张「当前 0 failed、8 pending」,不提前主张 full-green。

非阻塞观察(不改代码,留记录)

① src/server/handle.ts miss-fresh 分支那条 // #5608-B: no honest-NULL arm… 注释首行仍比同块多缩进一级(纯排版零行为)——本 PR 正待你对内核变更授权、且你在活跃推进(刚做了 master 同步),我推一个 commit 会再触发一轮 CI、又改 head,故仍留给你合并前顺手清(要我现在推也行,说一声即可)。
② PR 正文版本行仍写「0.0.180 → 0.0.181」,net diff 实为 0.0.185(max+1 后)——正文按规则我不代改(仅允许补 kernel-change 行,该行已在),提示更正。
③ seedTimestampsFromParent 整份携带父账本不按 incoming ids 过滤——孤儿条目内容寻址永远查不到、安全,只多占点字节,与其它 latch carry 风格一致(可接受)。

判定

master 同步合并干净正确,特性与上一轮我审的实现逐字一致、CI 无失败。但因触碰 kernel/(compress/refs/sync/types + 版本 0.0.185),按 Kernel Boundary 属人工审查层,我无法批准——请 owner 授权。详见下一条 🔶 需要决策。

@ranxianglei

Copy link
Copy Markdown
Owner Author

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

针对新 head 4eeb781f2(= 上一轮 27df6c616 + master d640d0d06 干净合并,kernel 版本 → 0.0.185)的内核变更授权请求,取代我 floor 57 那条(同一内核改动,现指向合并后的 head)。

PR #5609 触及 kernel/(正文带 kernel-change: #5608-B/C/D …),按 Kernel Boundary §2 属人工审查层,review worker 不得批准。被门控内核 diff:

独立评估见上一条 findings review:master 同步合并干净正确(union-of-intent、特性符号完整、共享内核文件零 churn)、实现正确、隔离良好、测试有牙、CI 无失败(8 shard 收尾中)。请求 owner 授权合并此内核变更。 needs-decision 标签已在 PR 上。

@ranxianglei

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b) PR #5609 复审完成(新 head 4eeb781f2)→ 仍需 owner 授权。新 head = 上一轮我审过的特性 + 干净的 master 同步合并(解决上轮 dirty 冲突)。已核:merge 为 union-of-intent、#5608-B/C/D 六个关键符号完整保留、四个共享内核文件零 churn、src/plugin.ts 与 master #4266 正确交织无矛盾、kernel 版本 → 0.0.185(max+1)、mergeable_state 由 dirty 转 blocked。特性代码与上一轮逐字一致,故维持「触碰 kernel/ → 需人工授权」判定。findings-only review + 🔶 需要决策 已发至 PR;CI 镜像缓存 {failed:0, pending:8}(无失败,8 test shard 收尾中)。等 owner 拍板合入。

@ranxianglei

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b) PR #5609(新 head 4eeb781f2)本轮复审已交付完毕:新 head = 我上一轮审过的特性 + 一次干净的 master 同步合并(解决上轮 dirty 冲突)。已核 merge 正确(union-of-intent、#5608-B/C/D 六个符号完整、四个共享内核文件零 churn、src/plugin.ts 与 master #4266 正确交织)、特性代码逐字未变、kernel 版本 → 0.0.185(max+1)、mergeable_state dirty→blocked。因触碰 kernel/,按 Kernel Boundary 属人工审查层,不批准;findings-only review(id 6701365489)+ 🔶 需要决策(id 6701365747)均已发至 PR,CI 镜像缓存 {failed:0,pending:8}(无失败)。结论:等 owner 授权内核变更,无其它待办。

ranxianglei added a commit that referenced this pull request Nov 7, 2026
…ses large histories locally; log every direct send with its size

Owner ruling 2026-11-07 (items 1-3 as one PR; item 4 deferred):

(1) Calibrated estimate tier. The shared over-window predicate now
    prices bodies at bytes/4 x CALIBRATED_TEXT_TOKEN_RATIO (1.14, the
    measured billing bias from #5613's session ledger) on top of the
    optimistic floor. The old bar is strictly nested: anything the floor
    already refused is still refused (provablyOver); anything only the
    calibrated estimate crosses is refused too, since direct-sending it
    was a coin flip weighted toward a guaranteed upstream 4xx. Missing
    data (no size / no window / undecodable stays all-core) keeps
    fail-open by construction.
(2) Large-history fail-close lands on BOTH gate arms: the thrown-
    attribution settle path (#2924/#3581/#5609 lineage) and the unattributed
    arm (#4068). Local refusal = 422 with the token math in the durable
    line; small lanes keep #1117 direct semantics byte-for-byte.
(3) Every bare DIRECT send now carries its body size (or an explicit
    'size unknown - the fuse could not run' note) and logs on a bounded
    cadence (first occurrence / state change / every 10th), so a leaking
    agentless lane can no longer stay silent after line one. Streamed
    bodies with a declared Content-Length are now priced from it instead
    of being skipped, so the fuse also arms for large streaming sends.
…→0.0.192 (max+1: master advanced 0.0.186–0.0.191 since d640d0d; branch carries #5608-B/C/D)
@ranxianglei

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

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

Conflict resolved and pushed (201775a6a6) — verified live first: a one-shot read of the PR object confirmed mergeable_state: dirty at head 4eeb781f2e (the mirror snapshot from earlier had not caught up; master had advanced further since run 1). Master was 544 commits ahead of our head (d640d0d06 → 4dea18eabf). Merged origin/master into the branch as merge commit 201775a6a6; the only textual conflicts were the acp-kernel version line (4 hunks, 3 files): branch 0.0.185 vs master 0.0.191 → resolved to 0.0.192 (max+1 — the merged tree carries master's unreleased 186–191 kernel changes AND our unreleased #5608-B/C/D kernel changes, so neither parent version corresponds to the union). All other content auto-merged clean with zero manual intervention, including src/fork-adoption.ts (master's #5968 retained-blocks recovery + our seedTimestampsFromParent), kernel/src/{compress,types}.ts, and src/server/handle.ts (26 master-side commits vs our weak-adoption gate). Push followed the new discipline: re-fetched before pushing, confirmed the remote head was still 4eeb781f2e (no concurrent push), plain fast-forward push, no force.

Environment note (transparency): between runs this sandbox was reset — node_modules fully wiped and the local branch pointer moved to an unrelated master commit. Repaired locally only (reset --hard to the true remote head + npm ci from the merged lockfiles); zero product-code impact.

七问:

  1. 是什么问题:分支落后 master 544 个提交(d640d0d → 4dea18e),GitHub 判 dirty(本轮已用一次性只读 API 核实,非凭旧评论);另有沙箱环境在两轮之间被重置(node_modules 丢失、本地分支指针被移到无关的 master 提交)。
  2. 怎么修的:先修环境(reset 本地到远端 head 4eeb781 + npm ci 恢复依赖——零产品代码改动);再用 merge commit 把 origin/master 合进分支(201775a)。文本冲突仅 4 处、全部是 acp-kernel 版本行(kernel/package.json ×1、kernel/package-lock.json ×2、根 package-lock.json ×1):分支侧 0.0.185 vs master 侧 0.0.191 → 按 max+1 裁定 0.0.192(合并树同时携带 master 未发布的 186–191 内核改动与本 PR 未发布的 # Cache hit collapses to 1–12% for a whole generation, then the very next request returns to 100% — repeated 15× in one day #5608-B/C/D 内核改动,两个父版本都不对应这个组合集)。其余文件 git 自动干净合并。
  3. 验证了什么:① 对称父 diff 零丢失证明——结果 vs master 父 = 恰好 PR 自身 24 文件集(内容仅 4 行版本号差异);结果 vs 分支父 = 恰好 master 实际改动的文件集(反向 gap 为空),两侧 hunk 零丢失;② typecheck clean(含 kernel/pi-subagents 构建);③ 定向测试而非本地全量:内核侧 32/32 绿(含双方同改、自动合并的 issue5608-timestamp-tails,及 master 新增的 New error in v0.213, following up on the previous bug where old blocks can't be compressed and tokens double. | 0.213版本新报错,接着上次的旧块无法压缩token翻倍bug #5919 shredded-merge、[PR] fix(nudge): no billing sample this round → hold pressure-band injection one round (phantom-pressure guard) #5860 pressure-hold 测试);宿主侧 128/128 绿 + 1 env-skip(plugin-fork、fork-adoption-plan——master 新测试验证我们同改的 fork-adoption.ts——、side-request-isolation、storage-unified、PR 核心 e2e resume-miss-timestamp-seed、issue4986 digest-drift)。全量矩阵判定交给推送后的 CI。
  4. 行为变更:产品代码零改动——仅一个 merge commit + 版本调和(PR head 处 acp-kernel 显示 0.0.192,合入后随 master 带走,属预期)。语义交互点已核:master 的 [Bug] Fork adoption drops retained folds deactivated by the source's last short view #5968 fork retained-blocks 恢复与我们的 seedTimestampsFromParent 同文件共存(master 新测试验证绿);master 的 Existing JSON State Files: Inventory and First-Batch Unified Storage Migration | 存量 JSON 状态文件:盘点与第一批统一存储迁移 #5753 unified kv_store 存储迁移(persist.ts 20 个提交)与我们 timestamp ledger 持久化路径交汇(storage-unified + issue4986 验证绿);master 的 ingest 闸/nudge credit window(handle.ts 26 个提交)与我们的 WEAK_ADOPT 门在不同区域,无重叠。
  5. 回归风险:自动合并文件逐个过语义冲突——仅我们改的 12 个文件与合并前分支版本逐字节一致(反向 gap 为空);3 个版本文件相对两父各只差版本行;其余经符号级核对确认双方关键符号齐全(seedTimestampsFromParent、WEAK_ADOPT_MIN_PREFIX_RATIO=0.8、timestampsHighWaterRefSeq、suppressMintingOnce、pendingLedgerAlign 链、master 侧 retained-blocks 逻辑)。未见语义破坏,最终判定以新矩阵为准。
  6. 门禁与决策:未触发任何新授权门禁;PR 正文一字未动。既有 🔶 待决项(owner 授权内核变更合入)仍然有效、未重复发——本轮是纯机械冲突处理 + 环境修复。
  7. 判定:冲突处置完毕,新 head 201775a6a6 已推送(push 前 fetch 确认远端 head 未变、plain push、无 force),等新 CI 全矩阵绿(镜像缓存此刻仍显示旧 sha 快照,轮询 ~1 分钟刷新,新 run 随后起);若仍有红我按车道继续接。合并权与内核变更授权仍在 owner 手里。

@ranxianglei
ranxianglei merged commit a51e11f into master Nov 10, 2026
56 checks passed
@github-actions

Copy link
Copy Markdown
Contributor

📦 Merged Build Published

This merge to master was published as 0.0.1168-master.a51e11f (rolling master tag).

npm install -g billion-context@0.0.1168-master.a51e11f  # this exact build
npm install -g billion-context@master  # always the newest merged build

npm view billion-context@master prints the current version at any time.

ranxianglei pushed a commit that referenced this pull request Nov 11, 2026
…6150 fold-point removal)

Master independently bumped the kernel to 0.0.193 for the compressAtFoldPoint
removal; this PR's overlap atomic-reject changes now sit on top of that, so
the version must move again (max+1, same precedent as #5609 sync). Both
lockfiles regenerated; diff vs master is only the kernel version lines.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant