[ranxianglei]

Closes #3663

What this fixes (diagnostics only — no overflow-check or metadata change)

Two of the four diagnostic defects reported in #3663 were still open on master after #3650/#3696 landed (facets A and D are fixed there — verified in-thread):

B — wall mislabeled. The preflight fail-fast headline said … exceeds the model window N even when N was bili's own OUTPUT-HEADROOM-reserved budget (native window − min(max_tokens, compress.outputHeadroomMaxPct × window); handle.ts rewrites modelContextLimit in place and records no shrink reason). The reporter's case: native 272000, reserved 68000, cited wall 204000 labeled "the model window". New exported helper buildEffectiveWallClause labels exactly the headroom shape as the effective input budget L (model window N, R tokens reserved for model output via compress.outputHeadroomMaxPct); every other shape (no reservation, operator/codex shrink, stated-wall overflow arm binding, unknown native window) keeps the historical wording byte-for-byte.

C — failed distillation attempts invisible. The tier-recovery detail counted only COMPLETED distillations (callsUsed), so a recovery whose summarizer failed/timed out read "0 summary call(s)" while the logs show the attempts happened. attemptTierRecovery now also counts committed dispatches (attemptsUsed, incremented before the summarizeRange await so throw/unusable/drift/refuse all count); the detail states N of M attempted summary call(s) completed only when some dispatch failed — byte-identical to the historical phrasing when every dispatched call completed.

Behavior changes (user-visible wording)

Surface	Old	New	When
fail-fast headline wall clause	exceeds the model window L	exceeds the effective input budget L (model window N, R tokens reserved for model output via compress.outputHeadroomMaxPct)	only when cited wall == config.modelContextLimit < resolved native window AND no operator/codex shrink reason (the headroom reservation alone explains the gap)
tier-recovery futile-round detail	(N summary call(s), net …)	(N of M attempted summary call(s) completed, net …)	only when a dispatched distillation did not complete (failed/timeout/unusable)

Both changes are additive diagnostics: no threshold, default, decision quantity, wire shape, or overflow check changed. This is NOT a weakening of any overflow gate and does not touch model metadata.

Config surface

None added/renamed/re-semantics'd. The message merely NAMES the existing compress.outputHeadroomMaxPct setting.

Tests

• tests/issue3663-preflight-diagnostic-labels.test.ts (new, 5 rows): wall-clause truth table (positive + 5 negative gates), end-to-end headroom label through startServer (max_tokens → reservation → 413 with the new label; absent without max_tokens), failed-dispatch visibility in the detail, completed-only byte-stability pin.
• Local targeted green (full-suite verdict = CI on this head): issue3663 (5), issue3645-calibrated-futility (4), issue2952-preflight-tier-recovery (4), fallback-window-floor (2), issue2317-route-miss-diagnostics (8), issue4185-identified-fresh-forward (4), issue4254-upstream-failure-egress (9), preflight-google-summary (2) + typecheck.

[github-actions]

📦 Built Package Artifact

Branch: 2026-10-24_preflight-diagnostic-labeling (42a544d)

Latest build — install this exact version

npm install -g [email protected]

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
42a544d	[email protected]	build
2ea6a72	[email protected]	build
4f69a63	[email protected]	build
98312af	[email protected]	build
8a5fa33	[email protected]	build
17fc477	[email protected]	build
d146325	[email protected]	build
52bda58	[email protected]	build

Download artifact

1. Download the artifact from the Actions run
2. Extract the tarball and install:

tar xzf billion-context-pr4618.tgz
npm install -g package

---

Install instructions are refreshed on each push.

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

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

CI auto-fix 车道判定(转发指向旧 head 52bda58,unused-exports):无需再推任何提交——该红已在分支上修掉且已转绿,剩余红全部是继承性 master 红。

独立核实(不照抄既有结论,live API + 本地复跑):

• 当前分支 head d14632554(在 52bda58 之上多一个独立标注 commit:fix: de-export ClientBuildCheck)。live check-runs 显示该 head 上 unused-exports ✅、全部静态门禁/guards/docs/lock-sync/build-artifact ✅;本地复跑 node scripts/check-unused-exports.mjs = ✓ unused-export gate: clean (6 waived)。
• 抽一个失败 test 分片日志核实签名:12 个 test 分片全部死在跑测试前——process-spawning test files missing from LIVE_FILES in scripts/run-ci-tests.mjs: tests/issue3890-parent-gone-confirm-drain.test.ts,与 CI Control Center: Centralized CI Failure Handling & Status Sync (Comment all CI issues here; do not open new issues) | CI 总控: CI 失败集中处理与状态同步(所有 CI 问题在此评论, 勿开新 issue) #4599 盘点第 2 条逐字一致(master 自身即红,[PR] fix(ci): clear the two master-red gates in one branch — unused-exports (#4602) + the #3890 LIVE_FILES tripwire (#4604) #4606 提交 2 修复中)。本 PR diff 未新增任何起子进程的测试文件。
• 本 PR 自身 diff(两个诊断文案改动)未引入任何 export 变化,unused-exports 报错行与 master tip 146b34f27 逐字节相同,纯继承。

八问

1. 是什么问题:CI 转发报 head 52bda58 的 unused-exports 红——实为继承自 master 的常红(ClientBuildCheck 僵尸导出),不是本 PR 代码引入。
2. 什么原因导致的:[PR] dsh lane: note in-session when running an unverified @deepseek-ai/dsh client build (soft, exact-match) #4545 train 落 master 后新增的 type-only 导出只在本文件内使用却带 export,de-export 清扫漏掉;每个 rebase 到 tip 的 PR 都继承同一报错行。
3. 影响范围与严重程度:仅 CI 信号面(检查矩阵失去该条信号),零用户侧影响。
4. 怎么修复的:分支内一行去 export,独立标注 commit d14632554(与 [PR] fix(ci): clear the two master-red gates in one branch — unused-exports (#4602) + the #3890 LIVE_FILES tripwire (#4604) #4606 提交 1 同法;几行级小修纪律允许重复修复,[PR] fix(ci): clear the two master-red gates in one branch — unused-exports (#4602) + the #3890 LIVE_FILES tripwire (#4604) #4606 合入后 rebase 时丢弃该 commit)。
5. 是否有回归问题:无——纯删 export 关键字,全仓零外部引用,dts/wire/决策面均不受影响,无行为变更。
6. 是否破坏缓存:不涉及。
7. 是否改了设计方向:没有。
8. 是否引入新配置:没有。

剩余红分账:12 个 test 分片 = 继承性 LIVE_FILES tripwire(#4599 盘点第 2 条,归 #4606/#1248)。处置:等 #4606 合并 → 本分支 rebase 重触发即全绿;rebase 时丢弃与 #4606 重复的 de-export commit。#4599 已有本帖两次分账记录(floor 33/34),不再重复评论。

结论:本车道目标检查(unused-exports)在现行 head 已绿,auto-fix 完成;PR 整体转绿唯一闸门是 owner 合并 #4606,之后 rebase 即可,无需其他动作。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

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

查重: 不重复 —— 本 PR 是 #3663 facet B+C 的唯一在途修复(A/D 已由已合并的 #3650/#3696 落地);其余在途 preflight PR(#3659 外部摘要诊断、#4294 fit 即停折、#4046 fold 持久化、#3590 marathon 墙钟)机制面均不重叠。
标签: bug / pi / codex / scope/kernel / p3(沿用 #3663 第 1 轮判定:纯诊断措辞缺陷,无功能影响;镜像 issue 原只有 pr 标签,已补齐)。

独立审核结论(对 diff 逐段重读,非转述 issue 侧分析)

① 方向关:两个缺陷在 master 上独立复现成立,PR 打点准确。

• B:master 上 fail-fast 标题硬编码 exceeds the model window ${limit}(src/server.ts:3624-3626 改动前文本);而输出预留走的是 per-request config 改写——src/server/handle.ts:2309-2310 reqConfig = { ...reqConfig, modelContextLimit: reserved },全程不记任何 shrink reason(handle.ts:826/829 是仅有的两处 reason 赋值:codex-align 与 operator-tuned),buildWindowShrinkNote 的门只认这两种 reason(src/server.ts:3628-3647)。纯预留场景下「model window」标签无来源可依,缺陷成立。
• C:callsUsed 只在蒸馏完整落地(apply 成功)后自增(src/preflight.ts:1955);throw(1919-1933)/unusable(1934-1938)/drift(1939-1943)/refuse(1947-1951)四条出口全部 break 不计数,失败恢复读作 0 summary call(s),缺陷成立。

② 回归审查(逐项审过的既有行为及结论):

1. 旧墙措辞的五个负形(无预留/operator/codex/stated-wall 低于配置值/native 未知)→ 保持:新真值表测试逐字节钉住(src/server.ts:3295-3309 的 gate 是四条件合取,任一不满足回退旧文案)。
2. 全仓唯一在带 max_tokens 场景断言旧措辞的既有测试 tests/issue4185-identified-fresh-forward.test.ts:236 → 保持绿:该场景 max_tokens=40000 恰等于窗口 40000,reserveOutputHeadroom(src/util.ts:578)的 maxOutput < window 守卫不成立、不发生预留,limit==native,旧措辞路径未变。本地实测绿。
3. tier-recovery 完成态旧措辞((N summary call(s), net …))→ 保持:attemptsUsed > callsUsed 才切新措辞,全完成时逐字节同旧文;新增 byte-stability 钉 + issue2952/issue3645 套件本地全绿。
4. buildWindowShrinkNote(窗口溢出报错 #736/Provider route miss silently drops per-model context override; 502 error then advises setting the already-set compress.modelContextLimit #2317 语义与逐字节钉)→ 未触碰,issue2317-route-miss-diagnostics 本地 8/8 绿。
5. 溢出判定量(limit 计算 src/server.ts:3345-3349、payloadFitsWindow、fold 逻辑)→ 零改动,阈值/默认值/时序/wire 形状均未动,overflow gate 未被放松。
6. d146325(ClientBuildCheck 去 export)→ 内部型、零外部引用(调用方按结构用 DSH_BUILD_CHECK),与 [PR] fix(ci): clear the two master-red gates in one branch — unused-exports (#4602) + the #3890 LIVE_FILES tripwire (#4604) #4606 提交 1 同法的继承红小修,commit message 已注明 [PR] fix(ci): clear the two master-red gates in one branch — unused-exports (#4602) + the #3890 LIVE_FILES tripwire (#4604) #4606 合入后 rebase 丢弃。无回归。

③ 代码审查发现(两条非阻塞边角,均非回归): 新标签在两个稀有角落会把预留归因到错误的设置项——

• proven-share 主导的墙(src/server/handle.ts:2305-2308):会话已有 [Bug][dsh native] preflight fold target sits ABOVE the engine's own denominator (1048576 vs 1000000) and the upstream-stated window from a 400 never feeds it — 'deficit 0' forwards an over-window payload → context_length_exceeded kills the turn #3450 实证 completion share 且它把墙压得比 pct 预留更低时,缺口由实证计费份额造成,但条款仍写 via compress.outputHeadroomMaxPct。触发需:同 origin+model 有既往溢出证据 + 当前 fail-fast 且 limit==configuredLimit。方向上仍是「bili 自己的预留」,只是指错了旋钮。
• fallback floor 封顶(src/server/handle.ts:2298-2301):低置信窗口源被 FALLBACK_EFFECTIVE_WINDOW_FLOOR 顶起时,floor 与 native 之间的缺口会被标成 outputHeadroomMaxPct 预留,实际钉墙的是 floor。需非权威窗口源才进入。
  两者都要求双重稀有前提、仅诊断措辞、旧文案在这些角落同样是错的(所以不是回归)。严格归因需要把预留来源从 handle.ts 穿进条款构造器(导出函数签名变更+新真值行),超出本 PR 的诊断范围;建议作为已知边界记录,owner 若在意可后续小修。PR 正文已有的「baseline-floor 引用量」残留备注与此同类。

④ 测试有效性: 5 行全部有牙——真值表正例+5 负门逐字节断言;端到端两方向(带 max_tokens 出 413 新标签 / 不带则旧标签且禁止出现 budget 字样,经真实 startServer 全链路);失败 dispatch 可见性(0 of 1 attempted … completed)+warn 日志双断言;完成态 byte-stability 钉。本地定向 11 文件 45/45 绿(含 PR 清单外但短语相关的 issue3918/preflight-multi-range/preflight-round-budget——三者只在自身断言消息里用词,不断言 wire 措辞,无风险)。

⑤/⑤b diff 与代码整洁: 4 文件 +385/−7,每行均服务于 B/C;两个 commit 标注清晰(修复 + 继承红小修独立成 commit)。命名达意(attemptsUsed vs callsUsed、headroomShrunk)、注释讲为什么且引号齐全(#3663/#736/#3450)、无死代码、风格一致。通过。

CI 状态(head d146325): unused-exports 与全部静态门禁/guards/docs/lock-sync 绿;剩余 11 个 test 分片红 = master 继承的 LIVE_FILES tripwire(与 master tip 同一签名,分片跑测试前即退出,已在 #4599 登记分账),等 #4606 合入后 rebase 重触发即绿,非本 PR 内容问题。

结构化八问

1. 是什么问题:preflight 拒绝诊断的两个盲区——输出预留后的有效输入预算被叫成「模型窗口」(读者去查模型元数据而不是控制该拒绝的设置),以及蒸馏调用发起过但失败时计数显示 0 summary call(s)(读者以为什么都没试)。
2. 什么原因导致的:报告层与决策层各取各的口径且信息丢失——handle.ts 为输出预留改写 per-request config 的 modelContextLimit 但不留 shrink reason,fail-fast 消息无从得知墙是谁设的,只能硬编码「model window」;tier-recovery 计数器设计为「已完成调用」,四条失败出口都不入账。
3. 影响范围与严重程度:纯诊断措辞,零判定/阈值/wire 形状变化,没有任何请求因此多拒或多转发。B 显现于发生真实输出预留的请求(非 anthropic wire,或无 separate-output-budget 证据的 anthropic 路由,带输出预算)撞上 preflight fail-fast;C 显现于 tier 蒸馏 dispatch 失败/超时。p3:误导成本是排障方向跑偏。
4. 怎么修复的:B 新增纯函数 buildEffectiveWallClause——当且仅当「被引用的墙 == 预留后配置值 < 解析出的 native window 且无 operator/codex reason」(此时只有 headroom 能解释差距)标为 effective input budget 并点名控制设置,其余形状逐字节保旧文;C 增加 attemptsUsed 在 dispatch 提交处(await summarizeRange 之前)自增,detail 仅在确有 dispatch 未完成时显示 N of M attempted … completed,否则逐字节同旧措辞。
5. 是否有回归问题:无。审过并逐项保持:五负形旧措辞(真值表钉)、无预留 e2e 旧措辞(钉)、唯一 max_tokens 场景旧措辞断言(issue4185:236,maxOutput==window 不预留故不受影响,实测绿)、完成态 tier 措辞(byte-stability 钉)、shrink note 语义(Provider route miss silently drops per-model context override; 502 error then advises setting the already-set compress.modelContextLimit #2317 钉)、overflow 判定量(零改动)。高危模式逐项过:无语义漂移、无吞错、无阈值/时序/输出格式漂移(除已披露的两处措辞)。上述 ③ 的两条边角归因不精确为已知边界,非回归。
6. 是否破坏缓存:不涉及——未触碰缓存键/重试/游标/去重策略。
7. 是否改了设计方向:不涉及——在既有 fail-fast/tier-recovery 路径内加诊断标注,无架构/边界转向。
8. 是否引入新配置:无——消息只点名既有的 compress.outputHeadroomMaxPct,无新 env/config/默认值。

行为变更披露(仅措辞,PR 正文表格属实):① 墙为 headroom 预留所设时,标题从 exceeds the model window L 变为 exceeds the effective input budget L (model window N, R tokens reserved for model output via compress.outputHeadroomMaxPct);② 蒸馏 dispatch 有失败时,futile-round detail 从 (N summary call(s), …) 变为 (N of M attempted summary call(s) completed, …)。两处均在特定形状下才出现,其余场景逐字节不变。

判定:内容面可合——方向正确、回归面逐项守住、测试有牙、diff 干净;唯二注意项是 ③ 的两条边角归因边界(建议记录,不阻塞)。合并路径:#4606 合入 → 本分支 rebase(丢弃 d146325 重复小修)→ 重触发全绿 → 人工合并。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

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

CI auto-fix 车道判定(attempt 2/2,head d146325,11 个 test 分片红):继承性 master 红,本车道不修——修复已在途(#4606),等合并后 rebase 即全绿。判定依据与上轮相同但独立复核过:

独立核实(抽 3 个失败分片日志跨平台覆盖:ubuntu-22-1、windows-22-4 job 120985916214、ubuntu-24-2 job 120985916179):

• 三个分片全部死在跑任何测试之前,签名逐字一致:process-spawning test files missing from LIVE_FILES in scripts/run-ci-tests.mjs: tests/issue3890-parent-gone-confirm-drain.test.ts. Register them there after reviewing their concurrency assumptions (#1248) —— CI Control Center: Centralized CI Failure Handling & Status Sync (Comment all CI issues here; do not open new issues) | CI 总控: CI 失败集中处理与状态同步(所有 CI 问题在此评论, 勿开新 issue) #4599 盘点第 2 条,master tip 自身即红,[PR] fix(ci): clear the two master-red gates in one branch — unused-exports (#4602) + the #3890 LIVE_FILES tripwire (#4604) #4606 提交 2 的修复对象。
• 刚查 [PR] fix(ci): clear the two master-red gates in one branch — unused-exports (#4602) + the #3890 LIVE_FILES tripwire (#4604) #4606 状态:仍 open、未合并(head 6d6ebb7d1f9)。
• 本 PR diff(两个诊断文案改动)未新增任何起子进程的测试文件,与本红零关联。在本分支重复 [PR] fix(ci): clear the two master-red gates in one branch — unused-exports (#4602) + the #3890 LIVE_FILES tripwire (#4604) #4606 的 LIVE_FILES 注册 = 重复修复且 rebase 时必然冲突,按查重纪律不做。

八问

1. 是什么问题:11 个 test 分片在 CI 入口 tripwire 处整体中止,一条测试都没跑——不是本 PR 任何代码的测试失败。
2. 什么原因导致的:tests/issue3890-parent-gone-confirm-drain.test.ts([Bug] Windows: Proxy falsely detects parent-gone and self-terminates on every forwarded request (same live PID triggered | [Bug] Windows：代理每转发一次请求就误判 parent-gone 自杀（同一存活 PID 在 2.5h 内触发 12 次） #3890 train 落 master)起子进程但未登记进 scripts/run-ci-tests.mjs 的 LIVE_FILES 白名单,CI 门禁 fail-fast;master 自身红,所有 rebase 到 tip 的 PR 继承。
3. 影响范围与严重程度:CI 信号面——所有基于当前 master 的 PR 测试矩阵全灭,用户侧零影响;对发版的阻塞由 CI Control Center: Centralized CI Failure Handling & Status Sync (Comment all CI issues here; do not open new issues) | CI 总控: CI 失败集中处理与状态同步(所有 CI 问题在此评论, 勿开新 issue) #4599 总控跟踪。
4. 怎么修复的:不在本车道修——修法已定且在途:[PR] fix(ci): clear the two master-red gates in one branch — unused-exports (#4602) + the #3890 LIVE_FILES tripwire (#4604) #4606 提交 2(登记该文件进 LIVE_FILES,含并发假设评审)。本车道动作 = 等 [PR] fix(ci): clear the two master-red gates in one branch — unused-exports (#4602) + the #3890 LIVE_FILES tripwire (#4604) #4606 合并 → rebase 本分支 → 重触发。
5. 是否有回归问题:无(本 PR 未动任何代码,仅诊断文案)。
6. 是否破坏缓存:不涉及。
7. 是否改了设计方向:没有。
8. 是否引入新配置:没有。

结论:attempt 2/2 用尽,判定为「非本车道小修」,停手。PR 转绿唯一闸门 = owner 合并 #4606;合并后我(或下条通知)rebase 重触发即可,无需其他动作。#4599 已有本 PR 分账记录(floors 33/34),不重复评论。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

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

本轮工作收口确认(完整审核结论见上条评论):

• 独立审核完成:facet B/C 在 master 复现成立、PR 打点准确;回归面逐项审过无回归(五负形旧措辞 byte-pin、issue4185:236 旧措辞场景实测绿、overflow 判定量零改动);两条边角归因边界已记录(proven-share / fallback-floor,非阻塞)。
• 本地定向验证:PR head d14632554 上 11 文件 45/45 绿。
• 标签已补齐:bug / pi / codex / scope/kernel / p3。
• CI:唯一红为 master 继承的 LIVE_FILES tripwire(ci-worker 车道已独立复核并登记 CI Control Center: Centralized CI Failure Handling & Status Sync (Comment all CI issues here; do not open new issues) | CI 总控: CI 失败集中处理与状态同步(所有 CI 问题在此评论, 勿开新 issue) #4599),非本 PR 内容问题。

当前状态:内容面可合,停手等外部闸门——owner 合并 #4606 后 rebase 本分支(丢弃 d146325 重复小修)→ 重触发全绿 → 人工合并。无需其他动作。