Skip to content

[PR] The DSH page explicitly states Node.js < 22 → upgrade to v22+ (when the proxy refuses to start) | DSH 页面明示 Node.js < 22 → 升级到 v22+(代理拒启时) - #5339

Open
ranxianglei wants to merge 3 commits into
masterfrom
2026-10-31_dsh-node22-page
Open

ranxianglei wants to merge 3 commits into
masterfrom
2026-10-31_dsh-node22-page

Conversation

@ranxianglei

@ranxianglei ranxianglei commented Oct 31, 2026 •

Copy link
Copy Markdown
Owner

DSH 页面明示:Node.js 低于 22 → 升级 Node.js v22+

什么坏了

DSH 的 lane 是插件自己拉起会话专属 bili 子进程(ensureProxyRunning({lane:"dsh"}),带 BILI_PARENT_PID 看门狗;用户不会也不应该手动启动 bili——手动实例会被拒绝 attach)。当本机 Node.js < 22(没有内置 node:sqlite)时:

  1. bili 子进程按"不降级"政策拒启并退出([storage] … requires Node.js 22 or newer);
  2. 插件侧捕获失败后模型流量降级直连、自动重播 respawn(这部分行为正确);
  3. 但 DSH 内嵌页面只显示通用的 "run /acp first, or launch through bili dsh" 降级提示——对一个 Node 版本不足导致的拒启,这条建议完全不对,用户不知道怎么修。

现在怎么治(owner 2026-10-31 定调:页面要明确告诉用户 Node.js 低于 22、需要升级到至少 22)

  • 宿主半边(src/agent/dsh-native.ts):新增 classifyBootstrapFailure(err)——只把 "no SQLite engine available" 一类错误分成 no-engine,其余一律 launch-failed(不误报升级)。bootstrap() 失败时把 {kind, detail} 记下来(respawn 每次重跑 bootstrap,最新失败永远生效),并在没有代理绑定时通过 __BILI__ 快照多发布一个 bootstrapFailure 字段(有代理绑定或无失败时 payload 与今天逐字节一致)。
  • 面板半边(src/agent/dsh-native-client.ts):zh/en 词典各加一条 degraded_node22——直白说明"本机的 Node.js 版本低于 22,压缩代理无法启动……请把 Node.js 升级到 v22+ 后重启 dsh;升级前会话照常工作,只是暂时没有上下文压缩"。两处降级渲染分支(sessions 页 / settings 页)按 kind 分流:no-engine 显示升级文案,其他情况维持原提示。旧宿主不带该字段时 fail-open 走原路径。

验证

  • tsc --noEmit 干净。
  • 测试:dsh-settings-ui + dsh-native 99/99 绿,其中两个新 facet:
    • index-inject 在无失败时 payload 与今天逐字节一致;seed no-engine 后同行携带 bootstrapFailure;
    • classifyBootstrapFailure 六例(三种 no-engine 形态 + ECONNREFUSED/readonly/undefined 归 launch-failed)。
  • DSH 相邻回归批(dsh-acp / dsh-admin-relay / dsh-panel-embed-cors / dsh-refresh / dsh-title-sidecar-handle)40/40 绿。

追加:顺手修好 master 基线上 3 个已红的守卫(与本 PR 无关,CI 连带失败)

CI 红了三个守卫 job,全部是 master 自身遗留、与本 PR 的 4 个文件无关:

Job 真凶 修法
docs-sync compress.promptPack seed 改了("chat" 包移除)但生成文档没跟着刷新 重新 generate
unused-exports src/codex-models.ts 的 CodexWindowSource 在 #5175 清理后无外部读者 去掉前导 export(仅本文件用)
lifecycle-ledger-guard BILI_SESSION_CONTENT_STORE_PIN(#5292)与 BILI_SPAWN_FINGERPRINT(#4125 tunnel PR)未登记 LIFECYCLE.md §2 permanent 表各补一行

本地验证:三个守卫脚本全过 + tsc 干净。

范围与边界

  • 只改 DSH 页面提示链路(4 文件:宿主 1、客户端 1、测试 2)。bili 进程自己的拒启日志措辞在 [PR] no-engine refusal: one line — requires Node.js 22+ #5326 里(同一个"requires Node.js 22 or newer"短语,两边口径一致)。
  • 不改 respawn/降级直连逻辑、不检查 DSH 宿主 node 版本(仓库现有底线 engines ≥20,node 20~22.4 有 better-sqlite3 自举兜底;<22 全死仅发生在下载被禁/失败时,那也会以 launch-failed 进入同一页面通道但保持通用文案)。

@github-actions

github-actions Bot commented Oct 31, 2026 •

Copy link
Copy Markdown
Contributor

📦 Built Package Artifact

Branch: 2026-10-31_dsh-node22-page (bdee188)

Latest build — install this exact version

npm install -g billion-context@0.0.9045-pr.5339.269ebce

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
bdee188 billion-context@0.0.9045-pr.5339.269ebce build
0a7bb82 billion-context@0.0.7671-pr.5339.115a502 build
46ab152 billion-context@0.0.7506-pr.5339.20b6900 build
9b90647 billion-context@0.0.7504-pr.5339.66a4416 build
80be076 billion-context@0.0.7491-pr.5339.45a6eb8 build
df9103d billion-context@0.0.7487-pr.5339.c87f49b build
a8ca718 billion-context@0.0.7481-pr.5339.e3c128b build

Download artifact

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

Install instructions are refreshed on each push.

@ranxianglei ranxianglei changed the title DSH 页面明示 Node.js < 22 → 升级到 v22+(代理拒启时) [PR] DSH 页面明示 Node.js < 22 → 升级到 v22+(代理拒启时) Oct 31, 2026
@ranxianglei ranxianglei changed the title [PR] DSH 页面明示 Node.js < 22 → 升级到 v22+(代理拒启时) [PR] The DSH page explicitly states Node.js < 22 → upgrade to v22+ (when the proxy refuses to start) | DSH 页面明示 Node.js < 22 → 升级到 v22+(代理拒启时) Oct 31, 2026
ranxianglei pushed a commit that referenced this pull request Oct 31, 2026
A success outranks an older recorded failure: after the user fixed the
environment (e.g. upgraded Node.js), a later unbind must not keep
advertising the stale no-engine error on the page. The superseded-flight
check stays first so a cancelled flight never clears another world's state.

Follow-up on #5339.
ranxianglei pushed a commit that referenced this pull request Oct 31, 2026
…r branches

no-engine publishes the upgrade wording (and suppresses the generic
/acp remedy); launch-failed and absent fields keep today's generic hint.
Covers both slots (settings.section, plugins.bundle.config).

Follow-up on #5339.
ranxianglei pushed a commit that referenced this pull request Oct 31, 2026
… pack is shipped)

The earlier regen in this PR dropped 'chat' because the seed predated
ci-fixes' seed repair; src/chat-pack.ts ships the pack, so the seed-side
fix is the correct convergence. Regenerating restores the chat row and
keeps docs-sync green on the merged tree.

Follow-up on #5339.
@ranxianglei

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

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

PR 审核结论(已核代码、补两个小修、已推分支)

审核方式:独立通读 PR head 80be076d5 全部 9 文件 diff(宿主/客户端/两测试 + 三个守卫修复),不照抄 issue 描述;随后按「小问题直接修」在 PR 分支补了 2 个标注 commit,又按 CI 协调政策 merge 了 ci-fixes。最终 head 46ab152a0。

八问

  1. 是什么问题:DSH 车道里 bili 子进程因本机 Node.js < 22(无内置 SQLite)拒启后,内嵌页面只显示通用的「先运行 /acp 或用 bili dsh 启动」降级提示——对版本不足这个真正原因,这条建议完全不对,用户不知道怎么修。
  2. 什么原因导致的:bootstrap 失败在宿主侧只记日志、没有分类也没有发布到面板可见的快照;客户端降级文案只有一条通用款,拿不到失败原因自然只能给通用建议。
  3. 影响范围与严重程度:仅 DSH 车道 + Node<22 机器(下载被禁/失败导致 better-sqlite3 自举也死掉的场景)。体验瑕疵级(p3):会话经直连照常工作,只是提示误导、压缩缺失且无修复指引。不影响其他车道、不影响代理模式。
  4. 怎么修复的:宿主半边把 bootstrap 错误分类为 no-engine(仅匹配 "no SQLite engine available" 一类,其余一律 launch-failed,保守不误报升级),失败记录随 respawn 每次刷新;仅在「无代理绑定且有失败」时往 __BILI__ 快照和 /bili/origin 多发布一个 bootstrapFailure 字段(两处快照≡路由)。面板半边 zh/en 各加一条直白的 degraded_node22 文案,sessions/settings 两处渲染分支按 kind 分流,旧宿主不带该字段时 fail-open 走原路径。
  5. 是否有回归问题:审过的既有行为逐项——① 无失败或已有绑定时快照 payload 与今天逐字节一致(PR 自带测试钉住,我复跑通过);② 两处渲染分支的我补了一个双向测试(no-engine → 升级文案且不含 /acp;launch-failed → 维持通用 /acp 且不提 Node.js),此前该分支零覆盖;③ 发现并修掉一个真缺陷:bootstrap() 成功路径不清除已记录的失败——用户升级 Node 后 respawn 成功,一旦之后走非 bootstrap 路径解绑(如 attach 超时),页面会持续显示过期的「升级 Node.js」提示。已在成功分支加一行清除(位于 supersede 检查之后,被取代的飞行不会误清另一世界状态);④ respawn/降级直连/watchdog 逻辑零触碰;⑤ 三个守卫修复本身:unused-export 去导出与 ci-fixes 同向收敛、LIFECYCLE 两行登记与 ci-fixes 一致、docs-sync 见下条披露。
  6. 是否破坏缓存:不涉及(未触碰任何缓存/重试/增量游标/去重键路径)。
  7. 是否改了设计方向:不涉及——纯增量诊断字段,复用既有 __BILI__ 快照通道,不改数据流。
  8. 是否引入了新的配置:无(不加 env/config/CLI flag)。

行为变更披露(Deliverables 第 4 条)

  • 新增可选字段 bootstrapFailure:默认不存在,旧客户端忽略,新客户端只在 no-engine 时换文案——纯增量,旧宿主逐字节不变。
  • 我补的清除语义:成功 respawn 后即使再解绑也不再显示旧失败提示(旧行为=会残留,属缺陷修复而非语义漂移)。
  • docs-sync 方向纠正:本 PR 早先的重生成把 promptPack 文档行的 "chat" 删掉了,但 src/chat-pack.ts 确实随包附带 chat pack——ci-fixes(701688d15)从种子侧修对了方向,我 merge ci-fixes 后已从修好的种子重新生成对齐。最终树:文档列出 "default", "lean", "chat"(与 master 手改意图一致,描述措辞更新为「项目包 → 用户包 → 随包附带(chat)→ 内置」,由生成器产出)。

CI 状态:旧 head 的红 = 继承性失败(master 同窗 docs-sync/unused-exports 红 + test 分片在档家族,#4599 floor 720 确认)。已按政策 merge origin/ci-fixes@0d69e2780,本地三守卫全绿 + tsc 干净 + dsh-native/dsh-settings-ui 100/100,新 head 46ab152a0 已推送,等 CI 重跑;test 分片若在档家族仍红属哨兵收敛范围,不在本 PR 夹带。

判定:代码面可合(两个小修已入分支);合入待 CI 在新 head 转绿。

@Louie0806

Copy link
Copy Markdown
Contributor

(ai: deepseek/deepseek-v41-flash)

Merge hazard: this PR will turn docs-sync red when merged onto current master

Not a review of the DSH-page content — that part is fine. This is about the two generated-docs files at the tail of the PR, which I tested by composing the PR into master and running the exact gate command.

What happens

#5339 head is 46ab152a0, merge-base with master is 485c5eaff. Composing it onto master (git merge --no-commit --no-ff) leaves no docs conflict, then:

$ node tools/gen-config-docs.mjs generate
$ git diff --exit-code -- CONFIGURATION.md CONFIGURATION.zh-CN.md website/main.js website/docs/index.html
exit=1

The two red lines are the compress.promptPack row, which the gate wants to change from

| `compress.promptPack` | string (builtin: "default", "lean") | …

to

| `compress.promptPack` | string (builtin: "default", "lean", "chat") | …

Why it slips through

It is a revert-then-keep shape, and neither side looks wrong on its own:

  • At the merge-base 485c5eaff, CONFIGURATION.md already carried "chat" — but the seed website/config-reference/compress.yaml did not. That was the #5319 docs-sync breakage.
  • Master since fixed the docs by regenerating from the seed: a4bbf470f / d2195b1d3 took the "chat" back out of CONFIGURATION.md (master's row today: "default", "lean").
  • #5339 carries commit 701688d15 ("repair docs-sync gates on ci-fixes"), which fixed the seed correctly (seed now has "chat") and regenerated the docs to match.
  • So relative to its own merge-base, #5339 changes nothing in the docs row, and relative to master, the docs row looks "already equal to base". The merge keeps master's stale lean-only docs while the seed says chat, and the generator then wants to rewrite them — hence a red required check on the merge commit.

Proof it is specific to this PR

I ran the same compose-and-generate on every open PR that touches the same seed, against current master:

pr5270   docs-sync GREEN
pr5316   docs-sync GREEN
pr5330   docs-sync GREEN
pr5334   docs-sync GREEN
pr5339   docs-sync RED  (CONFIGURATION.md, CONFIGURATION.zh-CN.md)

Minimal fix

Add one regenerated pair to the PR — i.e. rebase onto current master and re-run node tools/gen-config-docs.mjs generate, committing the two files. That seeds "chat" and brings the docs back in line, and the gate goes green:

composed tree, after taking the PR's seed side and regenerating:
GATE_EXIT=0

I verified that composition both ways, since #5339 is mergeable_state=dirty (textual conflicts on LIFECYCLE.md and src/codex-models.ts from its stale base) — the docs hazard is independent of those two conflicts and survives resolving them toward master.

Note on ordering with my lane

#5178 touches the same seed line (it is the promptPack docs-sync seed for the chat pack). If both land, whichever merges second must resolve website/config-reference/compress.yaml and website/docs/index.html — I measured that composition too and it is a one-line take-yours in each file, with the seed's messageTimestamps: true (master's current default) surviving intact and GATE_EXIT=0 afterwards. Order does not matter for correctness; only the second merger has to re-run the generator once.

I have not pushed anything for this — #5339 is yours and the fix is a rebase plus regeneration.

ranxianglei pushed a commit that referenced this pull request Nov 1, 2026
A success outranks an older recorded failure: after the user fixed the
environment (e.g. upgraded Node.js), a later unbind must not keep
advertising the stale no-engine error on the page. The superseded-flight
check stays first so a cancelled flight never clears another world's state.

Follow-up on #5339.
@ranxianglei
ranxianglei force-pushed the 2026-10-31_dsh-node22-page branch from 46ab152 to 0a7bb82 Compare November 1, 2026 09:08
ranxianglei pushed a commit that referenced this pull request Nov 1, 2026
…r branches

no-engine publishes the upgrade wording (and suppresses the generic
/acp remedy); launch-failed and absent fields keep today's generic hint.
Covers both slots (settings.section, plugins.bundle.config).

Follow-up on #5339.
@ranxianglei

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

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

已处理:分支重建到当前 master,docs-sync 合入隐患消除。新 head 0a7bb829f。

先说结论:你的分析完全正确,我按 compose-and-generate 复现了机制(base 有 chat / master 侧删掉 / PR 侧相对 base 未变 → git 取 master 的 lean-only 文档行 + 取 PR 的 chat 种子行 → 种子≠文档 → 门红)。但修法上我没有走「保留种子 chat + 重新生成」那条路,原因如下——

为什么选最小足迹而不是重新生成 chat 行

  1. 当前 master 是有意收敛到 lean-only 的:a4bbf470f(regenerate,New built-in chat prompt pack: default compression rules for long-term companionship / multi-session memory scenarios (e | 新增内置 chat 提示压缩包:长期陪伴 / 多会话记忆场景的默认压缩规则(compress.promptPack="chat" 启用) #5319 builtin chat pack)把 chat 从文档拿掉,且 master 的种子本来就是 lean-only——master 自身一致、门绿。PR 里那份 seed+chat 只是 ci-fixes 哨兵合并(701688d15)带进来的,与 master 方向相反。
  2. 你已确认 [PR] fix(#5175): strip drifted open-tag names and mid-turn draft envelopes #5178 拥有同一行种子(promptPack docs-sync seed for chat pack)。本 PR 若也携带它,谁后合谁就要解冲突;而且 chat pack 是否/何时入文档属于 packs 重做那条线的事(CI Control Center: Centralized CI Failure Handling & Status Sync (Comment all CI issues here; do not open new issues) | CI 总控: CI 失败集中处理与状态同步(所有 CI 问题在此评论, 勿开新 issue) #4599 floor 721「packs 重做中」),不该由一个 DSH 页面提示 PR 反向翻回。
  3. 三个守卫修复(LIFECYCLE 两行、codex-models/pack-install 去导出)master 已全部包含(逐一核过),本 PR 携带它们是冗余,也正是 stale base 产生 LIFECYCLE.md / codex-models.ts 文本冲突的来源。

具体操作:分支重置到 origin/master(7578e8184),只 cherry-pick 三个 DSH 专属 commit(原始实现 65122ddcb + 我的两个小修 9d6d6f2c5 clear-on-success、0a7bb829f render-branch 双向测试),作者信息保留。新 diff vs master = 恰好 4 个 DSH 文件(+114/−6),不碰任何生成物/种子/LIFECYCLE。

八问

  1. 是什么问题:旧 head 合入当前 master 时 docs-sync 必红(revert-then-keep 形状)+ stale base 文本冲突导致 mergeable_state=dirty,挡住合入。
  2. 什么原因导致的:master 在本 PR 分叉后独立收敛了 promptPack 文档(lean-only),而本 PR 经 ci-fixes 哨兵合并携带了相反方向的 seed+chat;三方合并把两边各取一半,种子与文档失配。
  3. 影响范围与严重程度:仅本 PR 的合入路径(CI 必红 + dirty 状态);零运行时影响,纯文档漂移。
  4. 怎么修复的:不是再补一次生成,而是把 PR 收敛回单一作用域——重建在最新 master 上、只留 DSH 三 commit;文档问题留给真正拥有该行的 [PR] fix(#5175): strip drifted open-tag names and mid-turn draft envelopes #5178。这样 compose 后生成器输出与 master 已提交产物逐字节相同,docs-sync 按构造绿。
  5. 是否有回归问题:DSH 代码与被审过的版本逐字节相同(同三个 commit 换基);diff 从 9 文件缩到 4;无新增行为变更。本地验证:typecheck 干净、dsh-native + dsh-settings-ui 100/100、三守卫全绿(docs-sync generate+diff 无漂移、unused-exports clean/8 waived、lifecycle-ledger OK)。
  6. 是否破坏缓存:不涉及。
  7. 是否改了设计方向:不涉及。
  8. 是否引入了新的配置:无。

行为变更披露(相对上一 head 46ab152a0):本 head 不再把 "chat" 加回 CONFIGURATION.md/zh-CN 的 promptPack 行——旧值(PR 曾恢复该行)= "default", "lean", "chat",新值 = 与 master 一致的 "default", "lean";原因见上,master 有意收敛、入文档归 #5178。DSH 页面提示的运行时行为不变。与你 #5178 车道的排序风险随之消失:本 PR 不再触碰 compress.yaml / index.html,谁先后合都不需要对方解冲突。

CI 状态:新 head 的运行刚触发(镜像缓存尚未收录,旧 head 的 30 项已全部完成作废)。静态面我已本地全绿验证;test 分片结果以 CI 为准。

判定:可合——待新 head CI 转绿即可由 owner 合入。感谢你的实证排查,compose 对照表(pr5270/5316/5330/5334 全绿、唯 pr5339 红)直接钉死了归因。

ranxianglei-devbox and others added 3 commits November 11, 2026 10:28
…cannot start (#5326 follow-up per owner)

The DSH lane auto-spawns its own bili proxy; when Node.js lacks the built-in
SQLite engine (<22) the process refuses to start and the embedded panel used
to show the generic 'run /acp first' degraded hint — wrong advice for this
failure. Now the host half classifies the bootstrap failure and publishes it
on the __BILI__ snapshot while no proxy is bound; the panel shows the
Node.js-upgrade text (zh/en) for kind no-engine, unchanged for anything else.
A success outranks an older recorded failure: after the user fixed the
environment (e.g. upgraded Node.js), a later unbind must not keep
advertising the stale no-engine error on the page. The superseded-flight
check stays first so a cancelled flight never clears another world's state.

Follow-up on #5339.
…r branches

no-engine publishes the upgrade wording (and suppresses the generic
/acp remedy); launch-failed and absent fields keep today's generic hint.
Covers both slots (settings.section, plugins.bundle.config).

Follow-up on #5339.
@ranxianglei
ranxianglei force-pushed the 2026-10-31_dsh-node22-page branch from 0a7bb82 to bdee188 Compare November 11, 2026 02:52
@ranxianglei

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

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

冲突已解并推送,新 head bdee1886d8,CI 全绿(52 checks:38 success + 14 skipped + 0 failed,经 GitHub 侧单次实读核验——镜像缓存在本次运行中停止刷新,按先例以 GitHub 为准)。

本轮做了什么

  1. rebase 到当前 master:分支原基线 7578e8184f(2026-11-01)已落后 master 199 个提交,四个 DSH 文件在 master 侧累计 +699 行改动([PR] fix: route DSH Codex Responses WebSocket through the native proxy #5839 dsh-codex-ws-lane、[PR] fix(storage): capture background integrity worker stderr — stop SQLite ExperimentalWarning leaking into the host TUI #5942 integrity-worker、[PR] fix(diagnostics): retain bounded private log history #5487 private-log-retention 等)。将三个 DSH commit(原始实现 + clear-on-success 小修 + render-branch 双向测试,作者信息保留)重放到当前 master。
  2. 唯一文本冲突:tests/dsh-native.test.ts 头部 import 块——master 侧已做 bodyProvablyOverWindow→bodyOverWindowDetail 改名并新增 installDshIntercepts、native-intercept/ws-intercept 两个 import,PR 侧在同一行追加了 classifyBootstrapFailure。解法:取 master 的完整 import 集 + 并入 classifyBootstrapFailure + 保留 PR 新增的六例分类测试;其余三文件自动合并后逐点核验,PR 全部 hunk 在新上下文里落位无误(bootstrap catch/success 两处、index-inject 与 /bili/origin 两处快照≡路由、客户端两渲染分支 + zh/en 词典)。
  3. 本地验证:typecheck 干净;dsh-native + dsh-settings-ui 定向套件 106/106 绿;净 diff vs master = 恰好 4 个 DSH 文件(+114/−6),无夹带。
  4. 推送:force-with-lease(推送前复核远端 head 未变,lease 钉在旧 head 0a7bb829fa)。
  5. CI 协调核查:master 当时双红车道(real dsh headless / real pi package-native,均为 ci:full 门控 e2e,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 上为 file-gate skipped,不继承该红,故未合 ci-fixes(同 [PR] fix(watchdog): terminate the serving process from fatal worker #5450 处置先例)。新 head 全绿,旧 head 那个 test ubuntu-22 shard 1 的单红未复现。
  6. 运行期间 master 又前移(合入 [PR] remove: the experimental compressAtFoldPoint feature — fold-point relocation (v1 #5471 + unreleased v2 #5949), #6132 #6150 remove-compress-at-fold-point):已核对该提交与本 PR 四文件零重叠,且本 head 上 docs-sync 门本地 exit=0(floor 6 那类 revert-then-keep 文档隐患不存在)。merge state 现为 behind,非 dirty——可正常合入;若 owner 偏好 up-to-date,合入前再同步一次即可,无需我预先动分支(避免作废刚跑绿的全矩阵)。

八问

  1. 是什么问题:PR 分支停留在 10 天前的 master 基线上,与快速推进的 base 产生文本冲突(merge state dirty),挡住合入。
  2. 什么原因导致的:master 分叉后对同一批 DSH 文件有大量独立演进(import 改名/新增模块),三方合并无法自动裁决 import 块的双方改动。
  3. 影响范围与严重程度:仅本 PR 的合入路径被挡;零运行时影响。
  4. 怎么修复的:rebase 重放三个 DSH commit 到最新 master,唯一冲突按 union-of-intent 解(master import 全集 + PR 的 classifyBootstrapFailure 及其测试),逐点核验语义 hunk 无损。
  5. 是否有回归问题:无——DSH 代码与被审过的版本逐字节相同(同三个 commit 换基);diff 范围不变(4 文件);typecheck + 定向套件全绿;CI 全矩阵绿。
  6. 是否破坏缓存:不涉及。
  7. 是否改了设计方向:不涉及。
  8. 是否引入了新的配置:无。

判定:冲突解除、CI 全绿,待 owner 合入(merge state:behind,不阻塞;需要的话我可以再同步一次最新 master)。

@ranxianglei

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

[ework] CI fix verified green ✓

@ranxianglei

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

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

本轮核查结论:「dirty」触发是过期状态,当前无冲突,未做任何改动。

本次实时核验(全部来自本 run 的活数据):

  • PR 分支远端 head 仍为 bdee1886d8(上一轮 rebase 推送的 head,无并发推送);master 仍为 33104b1f95,与上一轮结束时一致。
  • GitHub 单次实读:mergeable=True,mergeable_state=**behind**(非 dirty),state=open,未合并——上一轮 force-push 后的可合并性重算已完成,冲突不存在。
  • CI(镜像缓存,sha=bdee1886d8,04:05Z 刷新):total=30,failed=0,pending=0,无失败项。
  • 本地工作区干净,head 与远端一致。

「behind」是因为 master 在上一轮运行期间又前移(#6150);已核对该提交与本 PR 四个 DSH 文件零重叠、docs-sync 门在本 head 上 exit=0,不构成合入障碍。

判定:保持待 owner 合入状态,无需进一步动作;若希望分支与 master 完全同步再合,告知一声我再做最后一次同步。

@ranxianglei

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

[ework] CI fix verified green ✓

@ranxianglei

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

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

本轮核查(进程曾被强制重启,以下为重启后本 run 的实时核验)结论:「dirty」触发仍为过期状态,无冲突、无红 CI,未做任何改动。

活数据:

  • PR 分支远端 head 仍为 bdee1886d8(两轮前 rebase 推送的 head,无并发推送);master 期间又前进两个提交(e3220adc 合入 [PR] thirdparty-scan: flag dsh-live-compact as a known conflict (#5984) #6166 + 403c2752),已核对与本次 PR 的四个 DSH 文件零重叠。
  • 镜像缓存(05:02Z 刷新,sha=bdee1886d8):mergeable_state=behind(非 dirty),checks total=30 / failed=0 / pending=0。
  • 本地 docs-sync 门在本 head 上 exit=0。

「behind」不阻塞合入(AGENTS.md:BEHIND ≠ blocker)。PR 保持可合入状态,待 owner 合并;如需先同步最新 master 再合,告知一声即可。

@ranxianglei

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

[ework] CI fix verified green ✓

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants