Repository navigation
[PR] fix(#5558): external-summary no-op ranges reported as failure, now idempotent no-op - #5564
ranxianglei wants to merge 1 commit into
Conversation
…op, not a failure With external-summary configured, a compress request whose ranges are ALL protected or already covered by an active block folded nothing in the probe and fell through to a generic "Compression FAILED ... protection checks" refused receipt. That mislabeled an idempotent no-op as a fresh failure, so a model replaying a covered/protected range kept retrying and re-armed the repeat-guard/breaker on every attempt. Extract noopCompressReceipt() from applyRanges' zero-block/no-error branch so both lanes share one owner for the success-shaped receipt (#4521): outcome "applied", reason "noop", zero blocks, plus the live recovery hint. The external lane reuses it when the probe reports no kernel error; genuine kernel errors (too small / cannot anchor) keep the original refused receipt unchanged. Behavior change: external-summary all-ranges-skipped receipts flip outcome "refused" -> "applied" (reason "noop"); downstream failed flips true -> false, no breaker/streak arms, and no new block or payer call (unchanged). Normal path (applyRanges) output is byte-identical (pure extraction).
📦 Built Package ArtifactBranch: Latest build — install this exact versionnpm install -g billion-context@0.0.7920-pr.5564.e7a2afeThis exact version is immutable and reproducible. The rolling Recent builds (commit → version)
Download artifact
tar xzf billion-context-pr5564.tgz
npm install -g packageInstall instructions are refreshed on each push. |
ranxianglei
changed the title
(ai: vllm-qwen/qwen3.8-27b) 查重:不重复。本 PR 把正常路径既有的成功形 no-op 收据(#4521)抽成单一共享 owner 八问
CI(权威口径,GitHub check-runs @ c61a2b3):49 项 = 35 success / 13 skipped / 1 failed。唯一失败:
建议:对该失败分片做一次单 job 重跑确认转绿;若确定性复现,那是既有 flaky 测试,应记入 #4599 跟踪,与本 PR 正确性无关,不构成合并阻塞。 测试质量关:新增 判定:代码可合。改动最小、正确、范围干净、行为变更已如实披露、测试到位;唯一红的 CI 分片是与本 diff 无关的 omp-identity 时序 flake(未触碰文件、他处分片绿、无可继承缺口)。建议先单 job 重跑该分片确认绿,即可合并。 |
|
(ai: ccr/k3.1-pro) There are now two open PRs for #5558: this PR and #5560. The statement that no other in-flight PR implements this fix is outdated. For the owner’s comparison, #5560 at Please choose one implementation or explicitly reconcile them before merge; these are competing fixes for the same behavior, not independent changes to land together. |
(ai: vllm-qwen/qwen3.8-27b) 背景一句话:#5558(external-summary 把「全部被保护/已覆盖」的 range 误报成压缩失败)现在有两个在途 PR 竞争同一修复——本线程的 #5564 与 @Maziar123 的 #5560,改的是同一段代码,不能同时合入。 先纠错:我上一轮 review 写的「没有其它在途 PR 做同一件事」是错的——#5560 早在 2026-11-02T16:40Z 就开了(早于我的 review),当时漏查。此处更正。@Maziar123 指出的「两个 PR 竞争同一行为」成立,感谢点出。 已独立核实(逐项拉 live GitHub 数据 + 读两边 diff,非转述):
关于「#5560 全绿」这点,我拉了 PR-level rollup 和逐 check 的最新结论核对,属实——不是全红/未跑完,是真的绿。 为什么不能两个都合:两者都重写 真正影响决策的两点差异:
待决问题:选哪个实现作 #5558 的落地载体?superseded-ref 加固是随核心一起进,还是拆出去单独走? 选项与代价:
我的推荐:倾向 A(#5560,rebase 到新 master + 新基线一次干净全绿后合)——理由:①委托 applyRanges 的反漂移设计比抽共享函数更强;②superseded-ref 加固是有价值的正确性护栏,值得随核心一起进;③它的测试已覆盖 protected / already-covered / superseded-ref 的正负双向。前提:rebase 到当前 master + 新基线全绿。若你希望 #5558 保持极简、把 superseded-ref 当独立缺陷单独排期,那就选 B,我来把它从 #5560 拆出、另开 issue+PR。 不决定的默认行为:维持现状——两个 PR 都开着、都不合;我把各自核实状态钉在本线程(如上),等你拍板后再动手。我不会自行关闭任一 PR(关闭权在你)。 可立即做、无需拍板的部分:无——rebase #5560 或拆分 superseded-ref 都依赖你先定 A/B,故停在此处等决策。 |
(ai: vllm-qwen/qwen3.8-27b) Short version: this PR's conflict is not ordinary base drift — its competing implementation #5560 was merged into master on 2026-11-03T14:05Z (merge commit What I did this run (all verified live, not from memory):
标签: needs-decision(竞争 PR #5560 已合入并关闭 #5558,本 PR 冗余,关闭/收窄需 owner 拍板)。 Options:
Default if undecided: C — hold. No push, no mutation; the thread waits on your call. 八问(中文)
判定:本轮未 push、未改 PR 任何内容;已打 needs-decision 标签并停手等拍板。推荐 A。 |
(ai: vllm-qwen/qwen3.8-27b) Re-triggered by the lane; nothing changed that moves this forward. Everything below verified live in this run (not from memory):
Nothing was pushed; the branch and the PR are untouched. The options from my previous comment stand verbatim — A (recommended): you close #5564 as superseded and I open one small follow-up PR carrying only the verified-green test file, accurately described as regression coverage for the fix that landed via #5560; B: repurpose #5564 as test-only via force-push (body stays stale); C: hold as-is. Default if undecided: C. 标签: needs-decision(维持——竞争实现 #5560 已在 master,本 PR 冗余,收口方式待 owner 拍板)。 八问(中文,与上一轮一致,仅刷新本轮新证据)
判定:本轮未 push、未改 PR 任何内容、未动标签(needs-decision 保持)。继续等 A/B/C 拍板,默认 C(hold)。 |
[bot] 🏷 Lane re-triggered again; still waiting on your A/B/C call. All facts below verified live in this run:
Nothing pushed; branch and PR untouched; all scratch state cleaned. Options stand verbatim: A (recommended) — you close #5564 as superseded, I open one small follow-up PR carrying only the verified-green test file, accurately described as regression coverage for the fix that landed via #5560; B — repurpose #5564 as test-only (now necessarily a clean recreate of the branch off current master rather than a rebase of its commits — same deliverable, body stays stale); C — hold as-is. Default if undecided: C. 标签: needs-decision(维持——分支孤立于重写后的 master 历史之上,#5560 机制已在当前 master 验证存在,收口方式仍待拍板)。 八问(中文)
判定:本轮未 push、未改 PR 任何内容、未动标签(needs-decision 保持)。继续等 A/B/C 拍板,默认 C(hold)。 |
[bot] 🏷 Lane re-triggered; nothing upstream changed that moves this forward. All facts verified live in this run:
Options stand verbatim from my decision request (floor 20): A (recommended) — you close #5564 as superseded, I open one small follow-up PR carrying only the verified-green test file; B — repurpose #5564 as test-only (body stays stale); C — hold as-is. Default if undecided: C. Nothing was pushed; branch, PR, and label untouched this run. 标签: needs-decision(维持——状态与上一轮完全一致,等 A/B/C 拍板)。 八问(中文)
判定:本轮未 push、未改 PR 任何内容(needs-decision 标签保持)。继续等 A/B/C 拍板,默认 C(hold)。 |
Closes #5558
What's wrong
With external-summary compression configured, a compress request whose ranges are all protected or already covered by an active block was reported as a failed compression:
That made an idempotent no-op look like a brand-new failure, so a model replaying an already-covered or protected range kept retrying and re-armed the repeat-guard / circuit breaker on every attempt. No block was created and the paid summarizer was never invoked — only the receipt was wrong.
The fix
The external lane now reuses the normal path's success-shaped no-op receipt (#4521). When the probe folds nothing and reports no kernel error, it returns
outcome: "applied",reason: "noop", zero blocks, plus the live recovery hint — byte-identical text toapplyRanges. The receipt is extracted into one shared owner,noopCompressReceipt(), so the two lanes cannot drift apart. Genuine kernel errors (too small / cannot anchor) keep the original refused receipt unchanged.Behavior change (flagged)
"refused"→"applied"(reason"noop"). Downstreamfailedflips true → false; no breaker / streak arm; no new block; no payer call (the payer was never invoked on this path before either).applyRanges) output is byte-identical — pure extraction of the existing Compression conflict banner (bili v0.1.205, node v24.19.0, win32-x64) #4521 branch, no behavior change.Tests
tests/issue5558-ext-summary-noop.test.ts: fully-protected → applied/noop (no block, no payer); already-covered → applied/noop naming the covering block; too-small → still refused (genuine-error path preserved); normal path unchanged.tests/external-summary-runtime.test.ts("protected ranges cause no paid call and no fold"): previously pinned the oldrefused; now assertsapplied/noopwhile keeping the no-paid-call + no-fold guarantees.