fix(vscode): stop webview bundle test timing out under CI contention (#10665) - #10672
Conversation
…10665) The embedded-webview bundle guard drives esbuild across the whole webview app and takes ~6-9s even on an idle host, sitting right on vitest's 5s default testTimeout and over it on the shared ECS pool. The main-branch run for a8e0d29 failed exactly there: "Test timed out in 5000ms". Raise the per-test ceiling for packages/vscode-ide-companion the same way packages/core and packages/cli already do (60s on ecs-qwen-* runners, 15s elsewhere). Only the timeout ceiling grows; the bundle assertions are unchanged.
E2E Report — Issue #10665 (Main CI failed on a8e0d29)Failure diagnosisIssue #10665 tracks the
Root causeThat test drives Reproduced locally (this checkout, before the fix): A direct esbuild probe of the same entry point measures 6.3–7.1s per build on this 64-core machine, with the bundle assertions themselves satisfied (no FixRaised the per-test timeout ceiling in Post-fix, the same command passes: Mutation probe: with the pre-fix config the bundle test fails with the 5000ms timeout (recorded above); with the fix applied it passes. Removing the added Notes on other observations
Verification
中文说明E2E 报告 — Issue #10665（main 分支 a8e0d29 上 CI 失败）故障诊断Issue #10665 跟踪的是
根因该测试对 本地复现（本检出、修复前）： 对同一入口直接执行 esbuild 的探测显示：在这台 64 核机器上每次构建耗时 6.3–7.1 秒，且 bundle 断言本身是满足的（产物中不含 修复按照 修复后，同一命令通过： 变异探针：使用修复前的配置时，该 bundle 测试以 5000ms 超时失败（如上记录）；应用修复后通过。删除新增的 其他观察说明
验证
🧠 Handled by Qwen Code · model/模型 |
github-actions
Bot
added
the
review/self-reported
|
|
|
Thanks for the PR! Template looks good ✓ Problem: observed, with hard evidence — the Direction: aligned — this is CI stability on Size: not applicable — single config file outside core paths (+7/-0, all production lines). Approach: minimal and correct — adds only Risk: no elevated risk signals. Moving on to code review. 🔍 中文说明感谢贡献！ 模板完整 ✓ 问题：已观测到，且有硬证据 —— 方向：对齐 —— 这是 规模：不适用 —— 单个核心路径之外的配置文件（+7/-0，全部为生产行）。 方案：最小且正确 —— 只添加 风险：无升级风险信号。 进入代码审查 🔍 — Qwen Code · qwen3.8-max Reviewed at |
Code reviewNo blockers. My independent take on this problem was exactly what the PR does: raise Notes from the review:
Nothing user-visible here, so no real-scenario testing ( Testing evidenceThis is an unattended CI run, so no PR code was built or executed locally — the evidence below is this PR's own CI on the reviewed commit, fetched via the API. The lane that matters most for this change, Final CI results for
One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行（取最新一次运行），省略 skipped，失败项排在最前。 The claim being tested — the bundle guard completes within the new ceiling under ECS contention — is substantiated by exactly this CI job, since it runs the same suite on the same pool where the original timeout happened. 中文说明代码审查：无阻塞项。我独立的解法与本 PR 完全一致——在 测试证据：本次为无人值守 CI 运行，未在本地构建或执行任何 PR 代码；以上证据来自该 PR 自身在受审提交上的 CI（通过 API 获取）。对本改动最关键的 — Qwen Code · qwen3.8-max Reviewed at |
|
Confidence: 5/5 — the flake is real and verified end to end, and the fix is the smallest possible application of the repo's own established pattern. Stepping back: everything checks out. The problem was verified against the actual failing run's annotation, not taken on faith from the PR body. The fix is exactly the change I would have made independently — three config lines reusing the ECS-aware formula already in production in One remaining item is not in this run's hands: CI on the reviewed commit has not fully landed yet — the unit-test lane this change targets is still running. Approval is therefore deferred until CI lands green on 中文说明置信度：5/5 —— flake 真实存在且已端到端核实，修复是本仓库既有写法的最小化应用。 退一步整体看：各项都成立。问题是拿真实失败运行的注记核实过的，不是凭 PR 描述照单全收。修复方案与我独立得出的解法完全一致——三行配置，复用 唯一不在本次运行掌控中的事项：受审提交上的 CI 尚未全部结束——本改动针对的单元测试 lane 仍在运行。因此将批准推迟到该提交的 CI 全绿之后，本次运行不提交批准。 — Qwen Code · qwen3.8-max Reviewed at |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Not reviewed: reverse audit — stopped before round 1 by the review time budget.
Test Plan (not a blocker): src/utils/imageSupport.bundle.test.ts — no such file or directory.
中文说明
未审查：反向审计——评审时间预算不足，未能开始第 1 轮。
Test Plan（非阻断）：src/utils/imageSupport.bundle.test.ts — no such file or directory。
— qwen3.8-max via Qwen Code /review (v0.22.3)
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
|
E2E verification report — no Critical found (verification run + CI evidence; not an approval since the Test ubuntu lane is not green). Reviewed the full diff at head Evidence the fix addresses #10665:
One observation, unrelated to this PR (pre-existing): the lane's Status: yiliang114 has already approved this head. CI is not fully green at head (the unrelated web-shell timeouts above; the run's 中文说明E2E 验证报告——未发现 Critical（验证性报告；因 Test ubuntu 车道未绿，不作为 Approve）。 已审阅 head 修复有效性的证据：PR 自身 CI（run 33466380351）中 embedded webview 打包实测 9232ms——已超过旧的 5s 默认上限（即 #10665 的成因），在新上限下通过；整包 45 文件 / 509 测试全绿。本地对同一测试文件做 A/B（该文件 main 与 head 相同）：空闲 1.55s，16 核 顺带观察（与本 PR 无关）：本 head 的 Test ubuntu 失败是 7 个 web-shell 套件 状态：yiliang114 已批准该 head；但 CI 当前未全绿（上述无关的 web-shell 超时；同一 run 的 web-shell E2E Smoke 作业亦被取消），按规则此处不投 Approve——在健康 runner 重跑 Test 车道应能转绿。 |
|
🤖 AutoFix ran out of time before finishing (timeout (7200000ms)) (attempt 1/10) — it will retry on the next scan.
See the Qwen Autofix agent step logs for model/tool output. 中文说明🤖 AutoFix 在完成前耗尽了时间（timeout (7200000ms)）（第 1/10 次尝试）—— 将在下次扫描时重试。 Run log: https://github.com/QwenLM/qwen-code/actions/runs/33471581722 🧠 Handled by Qwen Code · model/模型 |
|
🔀 Base updated: red check(s) [Test (ubuntu-latest, Node 22.x)] pass on current main — merged current main via update-branch; CI will re-run. 中文说明🔀 已更新 base：红色检查 [Test (ubuntu-latest, Node 22.x)] 在当前 main 上通过 —— 已通过 update-branch 合入当前 main，CI 将重新运行。 |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed. Suggestions are inline.
Not explored to full depth (tool budget reached): "agent 4": none — no checks were cut short (well within the 32-call budget)..
Not reviewed: reverse audit — stopped before round 1 by the review time budget.
Test Plan (not a blocker): src/utils/imageSupport.bundle.test.ts — no such file or directory.
中文说明
仅完成部分审查，审查缺口已披露。 建议见行内评论。
未探索到全部深度（达到工具调用预算）："agent 4"：none — no checks were cut short (well within the 32-call budget).。
未审查：反向审计——评审时间预算不足，未能开始第 1 轮。
Test Plan（非阻断）：src/utils/imageSupport.bundle.test.ts — no such file or directory。
— qwen3.8-max via Qwen Code /review (v0.22.3)
Add a dedicated witness in scripts/tests/unit-vitest-configs.test.ts so a silent deletion or lowering of the bundle-guard timeout ceiling fails the scripts suite instead of reverting to vitest's 5s default and bringing back the #10665 flake class.
|
🤖 Addressed the latest review feedback (round 2/10). What changed, and what I pushed back on: · 已处理最新评审反馈（第 2/10 轮）。改动内容与我反驳保留之处如下： Autofix review round — PR #10672 (issue #10665)Commit this round: Feedback points and decisions[rc:3902221618] R2-1 [Suggestion] — witness test for the new it('keeps the bundle-guard timeout ceiling in packages/vscode-ide-companion', () => {
expect(vscodeCompanionConfig.test?.testTimeout).toBe(
process.env['RUNNER_NAME']?.startsWith('ecs-qwen-') ? 60_000 : 15_000,
);
});The expectation is computed from the same live [rv:5073966737], [rv:5075736668] — COMMENTED reviews, partially reviewed with disclosed gaps → no actionable finding. Both review bodies carry only the inline suggestion above (addressed) and gap disclosures. Their non-blocker note "Test Plan: [ic:5489890102] — E2E verification report from @qqqys → noted; its web-shell observation is deferred to the follow-up queue. The report finds no defect in this PR. Its side observation — Budget note: the previous round exhausted its time budget, so this round implemented only the minimal blocking subset — the single inline suggestion — and committed as soon as it was verified. Conflict notes: none ( Verification
中文说明Autofix 审查轮次 — PR #10672（issue #10665）本轮提交： 反馈点与处理决定[rc:3902221618] R2-1 [Suggestion] — 为新 it('keeps the bundle-guard timeout ceiling in packages/vscode-ide-companion', () => {
expect(vscodeCompanionConfig.test?.testTimeout).toBe(
process.env['RUNNER_NAME']?.startsWith('ecs-qwen-') ? 60_000 : 15_000,
);
});期望值用同一个实时 [rv:5073966737]、[rv:5075736668] — COMMENTED 审查，仅部分审查且已披露缺口 → 无可执行发现。 两个审查正文只包含上述行内建议（已处理）和缺口披露。其中非阻断备注"Test Plan： [ic:5489890102] — @qqqys 的 E2E 验证报告 → 已知悉；其 web-shell 观察转入后续跟进队列。 报告未发现本 PR 的缺陷。其顺带观察—— 预算说明：上一轮耗尽了时间预算，因此本轮只实现最小阻塞子集——唯一一条行内建议——并在验证完成后立即提交。 冲突说明：无（ 验证
🧭 Gate advisory — this round modified areas outside the PR footprint (machine-measured, not agent-authored):
Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 🧵 Resolved all 1 selected review thread(s). · 已关闭全部选中的 1 条评审线程。 Re-review when you have a moment. After round 10 this bot stops and leaves the PR for a human. · 有空请复审；第 10 轮后本 bot 停止并将 PR 交给人工。 🧠 Handled by Qwen Code · model/模型 |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Not explored to full depth (tool budget reached): "agent 6c": live execution of npm run test:scripts on this host — the shared worktree has no node_modules /built dist , and a full npm ci + npm run build was not fe….
Test Plan (not a blocker): src/utils/imageSupport.bundle.test.ts — no such file or directory.
中文说明
未探索到全部深度（达到工具调用预算）："agent 6c"：live execution of npm run test:scripts on this host — the shared worktree has no node_modules /built dist , and a full npm ci + npm run build was not fe…。
Test Plan（非阻断）：src/utils/imageSupport.bundle.test.ts — no such file or directory。
— qwen3.8-max via Qwen Code /review (v0.22.3)
|
🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下： Autofix review round — PR #10672 (issue #10665): no action neededHead Feedback points and decisions[rv:5077351917] — COMMENTED review, "Downgraded from Approve to Comment: CI still running" → nothing to implement. The review covered exactly the current head ( The review's execution gap ( "Test Plan (not a blocker): Failed check:
Conflict: none ( No commit this round; no threads required resolving; no inline findings open. Verification
中文说明Autofix 审查轮次 — PR #10672（issue #10665）：无需改动本轮未改动 head 反馈点与处理决定[rv:5077351917] — COMMENTED 审查，"已从批准降级为评论：CI 仍在运行" → 无需实现任何改动。 该审查覆盖的正是当前 head（ 审查披露的执行缺口（审查 worktree 中无 "Test Plan（非阻断）： 失败检查：
冲突： 无（ 本轮无提交；无需解决任何线程；没有未处理的行内发现。 验证
Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 🧠 Handled by Qwen Code · model/模型 |
|
🐑 Merge conflict with main detected — dispatched the autofix loop to resolve it. / 检测到与 main 的合并冲突，已触发 autofix 处理。 |
# Conflicts: # scripts/tests/unit-vitest-configs.test.ts
|
🤖 Addressed the latest review feedback (round 3/10). What changed, and what I pushed back on: · 已处理最新评审反馈（第 3/10 轮）。改动内容与我反驳保留之处如下： Round summary — PR #10672 (issue #10665)Feedback pointsNone actionable this round. The triaged feedback (reviews, inline comments, issue-level comments, failed checks) newer than the last evaluation (2026-09-01T11:25:19Z) was empty. The only prior inline finding (automated reviewer R2-1, asking for a witness test) was already addressed by the current head commit This round was triggered solely by ChangesMerged Conflict:
Resolution: kept both blocks verbatim — main's block first, then ours. They pin disjoint things and neither side altered the other's logic; taking only one side would have silently dropped a pin that each branch exists to enforce. The PR surface against Note: #10671 migrates the autofix verification gate off VerificationSee the Verification section below for every command run. Two environment anomalies surfaced during verification, both diagnosed to root cause with diff probes and both unrelated to the merge:
No mutation probe was needed this round: the merge commit adds no new guard, branch, or behavior — it only combines two previously witnessed blocks, and both witnesses are exercised green in the runs below. Verification
中文说明本轮总结 — PR #10672（issue #10665）反馈点本轮没有需要处理的反馈。上次评估（2026-09-01T11:25:19Z）之后的新反馈（评审、行内评论、issue 级评论、失败检查）均为空。此前唯一的行内发现（自动评审器 R2-1，要求补充见证测试）已由当前头提交 本轮仅由 变更内容将 冲突：
解决方式： 两个块都原样保留——main 的块在前，本 PR 的块在后。两者钉住的是互不相干的内容，任何一方都没有改动另一方的逻辑；只取一侧会悄悄丢掉各自分支赖以存在的钉住测试。PR 相对 说明：#10671 把 autofix 验证门禁从基于 验证所有运行过的命令见下方 Verification 小节。验证过程中出现两个环境异常，均已通过对照探针定位到根因，且都与本次合并无关：
本轮无需变异探针：合并提交没有新增任何守卫、分支或行为——它只是把两个早已有见证的块合在一起，而这两个见证都在下面的绿色运行中被执行到。 Verification
Base-conflict check · 基分支冲突检查: conflicted with main — resolved in this push. · 与 main 有冲突——已在本次推送中解决。 Re-review when you have a moment. After round 10 this bot stops and leaves the PR for a human. · 有空请复审；第 10 轮后本 bot 停止并将 PR 交给人工。 🧠 Handled by Qwen Code · model/模型 |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed.
Not explored to full depth (tool budget reached): "agent 3a": none — all planned checks completed (well under the tool budget)..
Not reviewed: reverse audit — stopped before round 1 by the review time budget.
Test Plan (not a blocker): src/utils/imageSupport.bundle.test.ts — no such file or directory.
Deferred under the convergence posture (round 4, not a blocker) — recorded, not requested in this round:
scripts/tests/unit-vitest-configs.test.ts:202 — [probe] witness test only pins the timeout branch its own lane selects (ECS 60_000 side never compared on hosted lanes)
中文说明
仅完成部分审查，审查缺口已披露。
未探索到全部深度（达到工具调用预算）："agent 3a"：none — all planned checks completed (well under the tool budget).。
未审查：反向审计——评审时间预算不足，未能开始第 1 轮。
Test Plan（非阻断）：src/utils/imageSupport.bundle.test.ts — no such file or directory。
收敛姿态下延后（第 4 轮，非阻断）——已记录，本轮不要求修改：共 1 条（原文未翻译，列表见上方英文部分）。
— qwen3.8-max via Qwen Code /review (v0.22.3)
|
🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下： Autofix round: no action takenThe round-4 review (
No commit was made; the branch stays at 中文说明Autofix 本轮：未做任何修改第 4 轮审查（
未创建任何提交；分支保持在 Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 🧠 Handled by Qwen Code · model/模型 |
Local verification report — real build, real runsVerdict: LGTM, safe to merge. I built both arms locally and reproduced the exact CI failure this PR fixes, then measured how much headroom the new ceiling actually buys. Everything the PR claims about the flake and the fix holds. One non-blocking nice-to-have on the new witness test, plus a couple of notes for the record. Reviewed at Harness — how the two arms were built (click to expand)Two git worktrees,
1. The flake is real, and this PR fixes itSame test file, same machine, same second — only the config differs:
2. How much headroom the ceiling actually buysRepeated trials rather than a single run, since the thing being fixed is a flake:
Reading of the table:
3. Everything else stayed green
Also verified live, by importing the real config files under different environments: Byte-identical to the ECS branch already in Assertions are genuinely untouched. Counterfactual: I forced the bundle guard to actually fail (made the forbidden-string assertion true). It fails as soon as the bundle finishes — it does not sit until the ceiling. Raising the ceiling does not hide a leaked Omitting 4. Nice-to-have (non-blocking): the new witness only pins one branch at a time
Three of four mutants escape in one environment or the other. Concretely: on the maintainer The test's comment says an env stubbed after import cannot work — but the sibling test in the very same file ( describe('bundle-guard timeout ceiling', () => {
it('keeps the bundle-guard timeout ceiling in packages/vscode-ide-companion', async () => {
for (const [runnerName, expected] of [
['ecs-qwen-parity', 60_000],
['ubuntu-latest-runner', 15_000],
] as const) {
vi.stubEnv('RUNNER_NAME', runnerName);
vi.resetModules();
// Re-imported under the stub: the config reads the env at import time,
// and the static import above already resolved one branch.
const mod = await import(
'../../packages/vscode-ide-companion/vitest.config.js'
);
expect(mod.default.test?.testTimeout, `RUNNER_NAME=${runnerName}`).toBe(
expected,
);
vi.unstubAllEnvs();
}
});
});Happy to see this merged as-is and fixed in a follow-up — it does not affect the production behaviour this PR is shipping. 5. Two smaller notes
中文版报告（点击展开）本地真实验证报告结论：LGTM，可以合并。 我在本地构建了两个分支（arm）并复现了本 PR 所修复的那次 CI 失败，随后量化了新上限究竟带来多少余量。PR 关于 flake 与修复的所有说法均成立。另有 1 条针对新增守卫测试的非阻塞改进建议，以及若干备查说明。 审阅提交： 验证环境两个 git worktree，
1. flake 真实存在，本 PR 确实修好了同一个测试文件、同一台机器、同一时刻，只有配置不同（见上方第一张截图）： 2. 新上限到底带来多少余量因为要修的是 flake，所以采用多次重复试验而非单次运行（见上方第二张截图）：
3. 其余各项均为绿色
另外通过在不同环境下真实导入配置文件做了实测： 断言确实未被削弱。 反事实验证：我强行让 bundle 守卫真的失败（把禁止字符串的断言构造为成立）。它在打包一结束就失败，并不会一直等到上限。提高上限不会掩盖泄漏进来的 不加 4. 非阻塞改进建议：新增的守卫每次只钉住一个分支
该测试的注释称"import 之后再 stub 环境变量不起作用"——但同一个文件里的兄弟测试（ 这条不影响本 PR 要发布的生产行为，按现状合并、后续单独跟进也完全可以。 5. 两点补充说明
|
…imeout ceiling (#10665) Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
|
🤖 Addressed the latest review feedback (round 4/10). What changed, and what I pushed back on: · 已处理最新评审反馈（第 4/10 轮）。改动内容与我反驳保留之处如下： Autofix review round for PR #10672 (issue #10665)Feedback this round: one issue-level comment from @wenshao ( 1. Witness only pins one
|
Mutant in packages/vscode-ide-companion/vitest.config.ts |
Result |
|---|---|
15_000 → 5_000 |
FAIL: RUNNER_NAME=ubuntu-latest-runner: expected 5000 to be 15000 |
60_000 → 15_000 |
FAIL: RUNNER_NAME=ecs-qwen-parity: expected 15000 to be 60000 |
condition startsWith('ecs-qwen-') → startsWith('nope-') |
FAIL: RUNNER_NAME=ecs-qwen-parity: expected 15000 to be 60000 |
| restored | 26/26 passed |
Note the second and third mutants escape the old witness on this runner (RUNNER_NAME unset here), and the first escapes it on the ecs-qwen-* lane — the new witness catches all of them in both environments.
2. Missing maxWorkers: '25%' in packages/vscode-ide-companion — deferred to follow-up
Real, reviewer-verified observation (packages/core and packages/cli cap workers; this package does not, so its 45-file suite contributes to oversubscribing shared ECS hosts). The reviewer explicitly scoped it out of this PR ("Worth considering separately — out of scope here"), so it is recorded in deferred-findings.json rather than implemented here.
3. Bundle guard dies with RangeError instead of a readable assertion — deferred to follow-up
Real, reviewer-verified, pre-existing and cosmetic: when the not.toContain guard fires, vitest diffs the ~32 MB string and throws RangeError: Invalid array length (exit code still 1 on all lanes, nothing swallowed). expect(output.includes('…')).toBe(false) would give a clean AssertionError. Outside this PR's timeout-ceiling purpose; recorded in deferred-findings.json.
4. PR body's "~6–9s even on an idle 64-core host" did not reproduce — acknowledged, no action
The reviewer measured 576 / 590 / 1098 ms idle builds of the identical bundle and notes this does not change the verdict (the failure is contention-driven and was reproduced). This is a note about the PR description's framing, not the code; this mode does not edit PR text. Recorded here for the record.
Dispositions
| Feedback point | Disposition |
|---|---|
Witness pins only the ambient branch (ic:5503336042 §4) |
Implemented — both branches pinned via stub + re-import; 3/3 mutants caught |
maxWorkers: '25%' missing (ic:5503336042 §5) |
Deferred to follow-up (deferred-findings.json) |
RangeError instead of readable assertion (ic:5503336042 §5) |
Deferred to follow-up (deferred-findings.json) |
Idle-time claim in PR body (ic:5503336042 §5) |
Acknowledged, no code action |
Commit: bc02aaeac4 — test(ci): pin both RUNNER_NAME branches of the vscode-ide-companion timeout ceiling (#10665) (1 file changed, 17 insertions, 6 deletions).
Verification
npx vitest run --config ./scripts/tests/vitest.config.ts scripts/tests/unit-vitest-configs.test.ts— 26/26 passed (baseline before the change, and after restoring the mutation probes)- Mutation probes: 3 mutants (
15_000→5_000,60_000→15_000, condition→nope-) each make the witness FAIL; restored config returns to 26/26 passed npm run build— passed (exit 0)npm run typecheck— passed (exit 0)npm run lint— passed (exit 0)- Integration tests after
npm run bundle— not run: the change is a test underscripts/tests/, not behavior exercised through the bundled CLI or integration harness npm run generate:settings-schema— not run: no settings source changed
中文说明
PR #10672（issue #10665）的 Autofix 审查轮次
本轮反馈：来自 @wenshao 的一条 issue 级评论（ic:5503336042）——一份本地 A/B 真实验证报告，结论为 LGTM，附带 1 条针对新增守卫测试的非阻塞改进建议，以及 2 点补充说明。没有行内评论、没有 review、没有失败的检查。无冲突（--conflict false），未合并 origin/main。
1. 守卫测试只钉住一个 RUNNER_NAME 分支 —— 已处理（已实现）
审查者对 63681ed 新增的守卫测试做了变异测试，发现 4 个变异体中有 3 个逃逸：因为断言复用了与配置相同的实时 process.env['RUNNER_NAME'] 表达式，实际只有当前环境选中的分支被钉住（例如在 ecs-qwen-* lane 上，把 15_000 改写成 5_000 仍然是绿的）。
已按审查者指出的手法重写 scripts/tests/unit-vitest-configs.test.ts 中的 bundle-guard timeout ceiling 测试——即同一文件中兄弟测试 autofix gate load clamps 已在使用的写法：vi.stubEnv + vi.resetModules + 在每个 stub 下动态重新 import。该测试现在在任何 runner 上（无论环境如何）都同时钉住两个分支（ecs-qwen-parity → 60_000、ubuntu-latest-runner → 15_000）。
对新守卫测试的变异探针（变异 → 运行 → 还原）：
packages/vscode-ide-companion/vitest.config.ts 中的变异体 |
结果 |
|---|---|
15_000 → 5_000 |
失败：RUNNER_NAME=ubuntu-latest-runner: expected 5000 to be 15000 |
60_000 → 15_000 |
失败：RUNNER_NAME=ecs-qwen-parity: expected 15000 to be 60000 |
条件 startsWith('ecs-qwen-') → startsWith('nope-') |
失败：RUNNER_NAME=ecs-qwen-parity: expected 15000 to be 60000 |
| 还原后 | 26/26 通过 |
其中第 2、3 个变异体在本机（未设置 RUNNER_NAME）会让旧守卫逃逸，第 1 个在 ecs-qwen-* lane 上会让旧守卫逃逸——新守卫在两种环境下全部捕获。
2. packages/vscode-ide-companion 缺少 maxWorkers: '25%' —— 转入后续跟进
真实且经审查者验证的观察（packages/core 与 packages/cli 都限制了 worker 数，本包没有，因此其 45 个测试文件的套件会加剧共享 ECS 主机的超额订阅）。审查者已明确将其划在本 PR 范围之外（"建议单独考虑，本 PR 范围之外"），故记入 deferred-findings.json，不在本轮实现。
3. bundle 守卫触发时报 RangeError 而非可读断言 —— 转入后续跟进
真实、经审查者验证、属于既有问题的外观性缺陷：当 not.toContain 守卫触发时，vitest 会对约 32 MB 字符串做 diff 并抛出 RangeError: Invalid array length（所有 lane 上退出码仍为 1，信号未被吞掉）。改成 expect(output.includes('…')).toBe(false) 会得到干净的 AssertionError。该问题在本 PR 的超时上限目标之外，记入 deferred-findings.json。
4. PR 描述中"空闲 64 核主机上约 6–9 秒"未能复现 —— 已知悉，无需处理
审查者对完全相同的产物实测空闲构建耗时 576 / 590 / 1098 毫秒，并注明这不改变结论（失败确由争用引起且已复现）。这是针对 PR 描述措辞的说明，不涉及代码；本模式不编辑 PR 文本，仅在此记录备查。
处置一览
| 反馈点 | 处置 |
|---|---|
守卫只钉住当前环境分支（ic:5503336042 §4） |
已实现 —— 通过 stub + 重新 import 钉住两个分支；3/3 变异体被捕获 |
缺少 maxWorkers: '25%'（ic:5503336042 §5） |
转入后续跟进（deferred-findings.json） |
RangeError 而非可读断言（ic:5503336042 §5） |
转入后续跟进（deferred-findings.json） |
PR 描述中的空闲耗时说法（ic:5503336042 §5） |
已知悉，无代码层面操作 |
提交：bc02aaeac4 —— test(ci): pin both RUNNER_NAME branches of the vscode-ide-companion timeout ceiling (#10665)（1 个文件，+17/-6）。
验证
npx vitest run --config ./scripts/tests/vitest.config.ts scripts/tests/unit-vitest-configs.test.ts—— 26/26 通过（改动前基线，以及变异探针还原后各一次）- 变异探针：3 个变异体（
15_000→5_000、60_000→15_000、条件→nope-）均使守卫失败；还原配置后恢复 26/26 通过 npm run build—— 通过（exit 0）npm run typecheck—— 通过（exit 0）npm run lint—— 通过（exit 0）npm run bundle后的集成测试 —— 未运行：本次改动是scripts/tests/下的测试，不属于经打包 CLI 或集成测试框架验证的行为npm run generate:settings-schema—— 未运行：未改动任何 settings 源
Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。
Re-review when you have a moment. After round 10 this bot stops and leaves the PR for a human. · 有空请复审；第 10 轮后本 bot 停止并将 PR 交给人工。
🧠 Handled by Qwen Code · model/模型 qwen3.8-max
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Not explored to full depth (tool budget reached): "agent 6c": local execution of scripts/tests/unit-vitest-configs.test.ts (no installed deps in the review worktree).
Test Plan (not a blocker): src/utils/imageSupport.bundle.test.ts — no such file or directory.
中文说明
未探索到全部深度（达到工具调用预算）："agent 6c"：local execution of scripts/tests/unit-vitest-configs.test.ts (no installed deps in the review worktree)。
Test Plan（非阻断）：src/utils/imageSupport.bundle.test.ts — no such file or directory。
— qwen3.8-max via Qwen Code /review (v0.22.3)
yiliang114
left a comment
yiliang114
left a comment
There was a problem hiding this comment.
Review passed.
Consistent with the repo's established clamp pattern: the embedded-webview bundle guard drives esbuild across the whole webview app and outruns vitest's 5s default under shared-runner contention, so the ceiling grows (60s on ecs-qwen-*, 15s elsewhere) while assertions still fail instantly. Both RUNNER_NAME branches are pinned by the new unit-vitest-configs test via re-import under stubs, matching how the core/cli/acp-bridge clamps are pinned. CI on this head still running; the change is test-timeout-only.
chiga0
left a comment
chiga0
left a comment
There was a problem hiding this comment.
No blocking findings.
Approval blockers: none.
Tier: Scan — test-infrastructure change only; no production code touched; no risk-score answers are yes.
Scope:
packages/vscode-ide-companion/vitest.config.ts— full file read at headscripts/tests/unit-vitest-configs.test.ts— diff and surrounding contextpackages/core/vitest.config.ts— full file read at head (pattern reference)packages/cli/vitest.config.ts— full file read at head (pattern reference)unit-vitest-configs.test.tsimport registry (lines 1–80) — verifiedvscodeCompanionConfigis already present
NOT reviewed: local execution (no node_modules in review environment); macOS/Windows behavior; ECS branch live run (unreachable outside ecs-qwen-* pool).
Cross-file checks:
-
Pattern match against core/cli:
testTimeoutvalues (60_000 onecs-qwen-*, 15_000 elsewhere) are byte-identical to the established pattern. The config omitshookTimeoutandmaxWorkersthat core/cli carry — deliberately: the failing test is a test-body timeout, not a hook timeout, and worker-count limits are not the stated concern here. The PR description calls this "the exact ECS-aware pattern" which is slightly loose, but the code is correct for its purpose. -
Registry coverage:
vscodeCompanionConfigis already imported and registered atscripts/tests/unit-vitest-configs.test.ts:34andconfigs["packages/vscode-ide-companion"]. The existingunhandled-error exemptiontest will exercise the new config without changes. -
New witness test: The
bundle-guard timeout ceilingtest stubsRUNNER_NAMEwithvi.stubEnv, resets the module cache withvi.resetModules(), re-importsvitest.config.js, and assertstestTimeout. Both branches (ECS 60_000 and non-ECS 15_000) are exercised independently of the actual runner. Thevi.unstubAllEnvs()call inside the loop correctly isolates iterations. Not circular — the expected values are hardcoded, not derived from the config. -
dangerouslyIgnoreUnhandledErrors: Already present in the config at head; no change needed.
Cross-check against prior reviews:
qwen-code-ci-botround 2 raised "testTimeout ceiling is pinned by no witness test" — resolved by the new test in this diff. Round 3–5: no further blockers. Round 4 noted (deferred) that the ECS branch is not exercised on hosted lanes — addressed byvi.stubEnvin the new test.yiliang114approved with a matching clean assessment.- No finding from prior reviews that I cannot rule on at head.
Reviewed with AI assistance.
6 participants
What this PR does
Raises the per-test timeout ceiling for the
packages/vscode-ide-companionvitest suite: 60s on the sharedecs-qwen-*self-hosted runners and 15s everywhere else, using the exact ECS-aware pattern already established inpackages/coreandpackages/cli. No test assertions change — only the ceiling grows.Why it's needed
The post-merge
Qwen Code CIrun on commit a8e0d29 (run 33452224969, tracked in the linked issue) failed in the unit-test step after every pre-test check had passed. The check-run annotation names the exact failure: the webview bundle guard inimageSupport.bundle.test.ts— "does not leave qwen-code-core runtime imports in the embedded webview bundle" — died withError: Test timed out in 5000ms.That test drives esbuild across
EmbeddedApp.tsx, which since the WebShell UI cutover pulls in the entire web-shell application and produces a ~32 MB bundle. Measured directly, that build takes ~6–9s even on an idle 64-core host, so it sits right on vitest's 5s defaulttestTimeoutand crosses it whenever a runner is contended. The suite was added without a raised ceiling, unlike sibling packages that already guard against this contention class — so main-branch CI flakes red with no code at fault.Reviewer Test Plan
How to verify
Run the affected test file on a clean checkout of the parent commit to observe the flake, then on this branch to observe the pass:
× ... does not leave qwen-code-core runtime imports in the embedded webview bundle → Test timed out in 5000ms.✓ src/utils/imageSupport.bundle.test.ts (2 tests) 8952ms, with the bundle assertions themselves unchanged and still enforced (no@qwen-code/qwen-code-coreortokenLimits.jsreferences in the bundle output).Also confirm the full package suite stays green:
cd packages/vscode-ide-companion && npx vitest run→ 45/45 test files, 509 passed | 1 skipped.Evidence (Before & After)
N/A (test-infrastructure change; no user-visible behavior. Test-run transcripts are in "How to verify".)
Tested on
Environment (optional)
Unit tests only (
vitest runinpackages/vscode-ide-companion), plus repo-wide build/typecheck/lint. The ECS branch of the timeout expression cannot be exercised outside theecs-qwen-*pool; it is byte-identical to the pattern already in production inpackages/coreandpackages/cli.Risk & Scope
packages/core/packages/clifor the same contention class.xz/pip3); both were green in the failing CI run and this change touches no shell or YAML. The other steps of the failing run were not re-audited — they all succeeded in it.Linked Issues
Fixes #10665
中文说明
本 PR 做了什么
提高
packages/vscode-ide-companionvitest 套件的单测超时上限：在共享的ecs-qwen-*自托管运行器上为 60 秒，其他环境为 15 秒，使用与packages/core和packages/cli中完全相同的、按 ECS 感知的既有写法。测试断言没有任何变化——只是上限提高。为什么需要
commit a8e0d29 的合并后
Qwen Code CI运行（run 33452224969，见关联 issue）在所有测试前检查全部通过之后，于单元测试步骤失败。check-run 注记明确指出了失败点：imageSupport.bundle.test.ts中的 webview bundle 守卫——"does not leave qwen-code-core runtime imports in the embedded webview bundle"——以Error: Test timed out in 5000ms失败。该测试对
EmbeddedApp.tsx执行 esbuild 打包；自 WebShell UI 切换之后，该入口会拉入整个 web-shell 应用，产物约 32 MB。直接实测显示：即使在空闲的 64 核机器上，该构建也需要约 6–9 秒，正好压在 vitest 默认 5 秒testTimeout的边缘，运行器一旦繁忙就会超时。该套件新增时没有提高超时上限，而同级包早已为同类资源争用问题做了防护——于是 main 分支 CI 会在代码没有任何问题时随机变红。审阅者测试计划
如何验证
在父提交的干净检出上运行受影响的测试文件以观察抖动，再在本分支上运行以观察通过：
× ... does not leave qwen-code-core runtime imports in the embedded webview bundle → Test timed out in 5000ms。✓ src/utils/imageSupport.bundle.test.ts (2 tests) 8952ms，bundle 断言本身保持不变且仍然生效（产物中不含@qwen-code/qwen-code-core或tokenLimits.js引用）。同时确认该包全量套件保持绿色：
cd packages/vscode-ide-companion && npx vitest run→ 45/45 个测试文件，509 通过 | 1 跳过。证据（修改前后）
N/A（测试基础设施改动；无用户可见行为。测试运行记录见"如何验证"。）
测试环境
环境（可选）
仅单元测试（在
packages/vscode-ide-companion中运行vitest run），外加全仓库的 build/typecheck/lint。超时表达式中的 ECS 分支无法在ecs-qwen-*资源池之外实际执行；它与packages/core和packages/cli中已在生产运行的写法逐字节一致。风险与范围
packages/core/packages/cli早已为同类资源争用问题接受了同样的权衡。xz/pip3）；两者在失败的 CI 运行中均为绿色，且本次改动不涉及 shell 或 YAML。失败运行中的其他步骤未重复审计——它们在该次运行中全部成功。关联 Issue
Fixes #10665