fix(tests): apply integration worker limits to forks - #8689
Merged
Conversation
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Collaborator
Author
Vitest forks worker-limit reportReproductionThe configuration contract test was first run against the previous integration configuration and failed: Vitest 3.2.4 defaults to Results
Vitest forks worker 限制报告复现配置契约测试首先在旧 integration 配置上运行，并按预期失败： Vitest 3.2.4 默认使用 结果
|
Collaborator
Collaborator
Author
|
@qwen-code /takeover |
qwen-code-dev-bot
added
the
autofix/takeover
Collaborator
|
🤝 Takeover engaged: the autofix loop now manages this PR — it will address new review feedback and resolve base conflicts until the label is removed or the round cap is reached. Remove the 中文说明🤝 已接管：autofix 循环现在管理此 PR —— 将持续处理新的评审反馈与 base 冲突，直到移除标签或达到轮次上限。移除 |
Collaborator
|
Re-run on Template: complete ✓ — all sections present, including the bilingual summary. Problem: real, and now verified from source rather than taken on faith. On Direction: aligned — this is precisely the fix the review comment on #8685 asked for; test-infra reliability with no product surface. Size: no core paths touched ( Approach: minimal and complete — declare the pool explicitly, move the bounds to Risk: no high-risk paths matched. Moving on to code review. 🔍 中文说明re-run（ 模板：完整 ✓ —— 各节齐全，含双语摘要。 问题：真实存在，且已从源码核实而非仅凭描述。 方向：对齐 —— 这正是 #8685 评审评论要求的修复；测试基础设施可靠性，不涉及产品面。 规模：未触及核心路径（ 方案：最小且完整 —— 显式声明 pool、把上下限迁移到 风险：未命中高风险路径。 进入代码审查 🔍 — Qwen Code · qwen3.8-max Reviewed at |
Collaborator
|
Code review — no blockers; the diff matches my independent proposal exactly. Given "the integration worker limits sit under Verified against the lockfile-exact vitest 3.2.4 source:
Contract coverage is complete: the new config test pins pool + bounds + absence of Non-blocking follow-up: the same latent mismatch exists in Testing — the PR's own CI at the reviewed commit, read via the API:
The required ubuntu job exercises the changed surface directly. From its log: the scripts suite passed 50/50 files including the new The earlier verify review's concern (integration suite never executed) is resolved at this head: the no-AK gate is an integration run through the changed config, and it ran here; the merge_group-only check cannot run on This is test-runner configuration pinned by contract tests plus a real gate run on the commit — no behavioural product claim is left unsubstantiated, so no sandboxed lane is needed. A 中文说明代码审查 —— 无阻塞项；diff 与我独立构思的修复方案完全一致。 如果让我独立修"integration worker 限制写在 已对照 lockfile 精确锁定的 vitest 3.2.4 源码核实：
契约覆盖完整：新配置测试锁定 pool + 上下限 + 非阻塞跟进：同样的潜在错配还存在于 测试 —— 被审提交上 PR 自身的 CI，经 API 读取（表格见上，此处以文字概述）： 必需的 ubuntu job 全部通过，且直接覆盖了改动面。从其日志可见：scripts 套件 50/50 文件通过，包括新增的 此前 verify 评审的疑虑（integration 套件从未运行）在本 head 已消解：no-AK gate 本身就是走改动配置的一次 integration 运行，且本次已执行；merge_group-only 的检查按工作流设计无法在 这是由契约测试锁定、且在该提交上有真实 gate 运行的测试运行器配置 —— 没有未被证实的产品行为声明，因此不需要沙箱验证通道。若维护者仍想要隔离深检，本线程中似乎已有一个 — Qwen Code · qwen3.8-max Reviewed at |
Collaborator
|
Confidence: 5/5 — premise verified from first principles, fix is the minimal correct shape, and every changed surface is pinned by tests and ran green at this commit. Stepping back: the problem was observed, not hypothesized — worker RPC timeouts on the integration legs in #8685, diagnosed in review as an inert worker limit. Rather than trust the PR body, I re-derived the mechanism from the pinned vitest 3.2.4 source: Results match the promise: at this head the required ubuntu job ran the new contract test green and the no-AK gate completed 11/11 integration files through the changed config with the two-fork cap. The earlier blocker (integration suite never executed) no longer stands — the gate is an integration execution of the changed surface; the merge_group-only check cannot run on PR events by design, and holding the PR for it would mean waiting on something no PR can provide. Scope stayed honest: five files, no drive-by changes, and the body flags the adjacent 中文说明回顾全局：问题是观察到的，不是假设 —— #8685 中 integration 腿出现 worker RPC timeout，评审诊断为 worker 限制不生效。我没有轻信 PR 描述，而是从锁定的 vitest 3.2.4 源码重新推导了机制： 结果与承诺一致：在本 head 上，必需的 ubuntu job 跑绿了新契约测试，no-AK gate 以两 fork 上限走完改动配置的 11/11 个 integration 文件。此前的阻塞项（integration 套件从未运行）已不成立 —— gate 本身就是对改动面的一次 integration 执行；merge_group-only 的检查按设计无法在 PR 事件运行，拿它卡 PR 等于等待任何 PR 都给不出的东西。 范围保持诚实：五个文件，无顺手改动，正文明确把相邻的 — Qwen Code · qwen3.8-max Reviewed at |
Contributor
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. |
qwen-code-ci-bot
approved these changes
Aug 7, 2026
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
LGTM, looks ready to ship — CI landed green after the review. ✅
qwen-code-ci-bot
requested changes
Aug 7, 2026
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
Not reviewed: build-and-test — Integration Tests (CLI, No Sandbox) was skipped in CI and its suite did not run locally.
中文说明
未审查：build-and-test — Integration Tests (CLI, No Sandbox) was skipped in CI and its suite did not run locally。
— qwen3.8-max via Qwen Code /review (v0.21.7)
Comment on lines
+32
to
+34
| forks: { | ||
| minForks: 2, | ||
| maxForks: 4, |
Collaborator
There was a problem hiding this comment.
[Critical] The config-level maxForks: 4 added here silently overrides the unchanged test:integration:no-ak:sandbox:none script's explicit --maxWorkers 2, so the required no-AK CI gate now runs at up to 4 fork workers instead of the declared 2.
Vitest 3.2.4's createForksPool resolves the worker cap as poolOptions.forks.maxForks ?? config.maxWorkers ?? cpus-1, and Vitest's own docs state poolOptions.forks.maxForks has higher priority than maxWorkers. Before this PR the integration config had no poolOptions.forks block, so the script's --maxWorkers 2 resolved to an effective cap of exactly 2 forks; with this PR the config's maxForks: 4 wins and the effective cap becomes 4 (min 2). The pinned --maxWorkers 2 flag becomes a dead switch, and both new contract tests stay green — one checks only the config object, the other only the two SDK script strings. This recreates, for the third invocation style, the exact silent option-ineffectiveness class this PR exists to fix.
— Failure scenario: the no-AK gate (ci.yml) spawns real CLI/daemon/fake-server subprocesses per fork on shared, oversubscribed runners; doubling its concurrency increases the I/O pressure that #8685 was fixing and makes [vitest-worker]: Timeout calling "onTaskUpdate" failures more likely on the very gate whose 2-worker bound the #8685 review discussion relied on. Reproduced empirically against this repo's vitest 3.2.4: an identical probe suite ran 2 concurrent workers under the pre-PR config shape and 4 under this config, both with --maxWorkers 2.
Suggested fix — migrate the no-AK script to the same mechanism this PR uses for the two SDK scripts (a CLI-set maxForks wins the same ?? chain), and update the exact-string pin accordingly:
// package.json — test:integration:no-ak:sandbox:none
- vitest run --root ./integration-tests --maxWorkers 2 ./fake-openai-server.test.ts ...
+ vitest run --root ./integration-tests --poolOptions.forks.maxForks 2 ./fake-openai-server.test.ts ...// scripts/tests/no-ak-integration-ci.test.js — update the pinned script string to match中文说明
此处新增的配置级 maxForks: 4 会静默覆盖未改动的 test:integration:no-ak:sandbox:none 脚本中显式的 --maxWorkers 2，导致必需的 no-AK CI gate 实际以最多 4 个 fork worker 运行，而不是声明的 2 个。
Vitest 3.2.4 的 createForksPool 按 poolOptions.forks.maxForks ?? config.maxWorkers ?? cpus-1 解析 worker 上限，且 Vitest 官方文档明确 poolOptions.forks.maxForks 优先级高于 maxWorkers。本 PR 之前 integration 配置没有 poolOptions.forks 块，脚本的 --maxWorkers 2 生效上限恰好为 2 个 fork；本 PR 之后配置里的 maxForks: 4 优先，实际上限变为 4（min 2）。被钉住的 --maxWorkers 2 成为死开关，而两个新契约测试仍然为绿——一个只检查配置对象，另一个只检查两条 SDK 脚本字符串。这在第三种调用方式上重新引入了本 PR 要修复的「选项静默失效」同类问题。
— 失败场景：no-AK gate（ci.yml）每个 fork 都会在共享、超售的 runner 上拉起真实的 CLI/daemon/fake-server 子进程；并发翻倍会加剧 #8685 正在修复的 I/O 压力，使 [vitest-worker]: Timeout calling "onTaskUpdate" 更容易出现在这个 #8685 review 讨论中明确依赖 2-worker 上限的 gate 上。已用本仓库的 vitest 3.2.4 实测复现：同一 probe suite 在旧配置形态下为 2 个并发 worker，在本配置下为 4 个，两者都带 --maxWorkers 2。
建议修复——把 no-AK 脚本迁移到本 PR 用于两条 SDK 脚本的同一机制（CLI 设置的 maxForks 在同一条 ?? 链中优先），并同步更新精确字符串断言（见上方代码块）。
— qwen3.8-max via Qwen Code /review (v0.21.7)
Collaborator
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Collaborator
|
🤖 Addressed the latest review feedback (round 1/100). What changed, and what I pushed back on: · 已处理最新评审反馈（第 1/100 轮）。改动内容与我反驳保留之处如下： Autofix round summary — PR #8689 (commit c220c8b)Feedback points and dispositions1. [Critical, rc:3736377964] Config
|
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
Reviewed. Not reviewed: build-and-test — Integration Tests (CLI, No Sandbox) was skipped in CI (merge_group-only) and its suite did not run locally. Not reviewed: build-and-test — Test (ubuntu-latest, Node 22.x) failed at the 'Install linters' setup step (curl network error) before its 'Run required no-AK integration gate' step ran; the no-AK integration suite did not run locally.
中文说明
已审查。 未审查：build-and-test — Integration Tests (CLI, No Sandbox) was skipped in CI (merge_group-only) and its suite did not run locally。 未审查：build-and-test — Test (ubuntu-latest, Node 22.x) failed at the 'Install linters' setup step (curl network error) before its 'Run required no-AK integration gate' step ran; the no-AK integration suite did not run locally。
— qwen3.8-max via Qwen Code /review (v0.21.7)
Collaborator
|
🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下： Autofix round summary — PR #8689 (no code changes)This round's only feedback is two failed checks, with no review comments:
After an evidence-based investigation (detailed below), neither failure is attributable to this PR's changes, and no code-level defect was found to fix. No code changes are made this round. Feedback points and dispositions1. [Failed check]
|
Collaborator
|
🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下： Autofix review round — no action requiredFeedback triaged this round: one automated review (COMMENTED, round 2, zero findings). No inline comments, no issue-level comments, no failed checks, and no still-red checks were reported. Decision: no code changes. The single review since the last evaluation is an informational coverage note from the automated reviewer, not a finding. Its two "Not reviewed" items were verified against the workflow and this PR's diff:
Nothing in the feedback names a defect, requests a change, or asks a question, so there is nothing to fix, decline, or escalate. 中文说明Autofix 审查轮次 — 无需处理本轮分类的反馈： 一条自动审查（COMMENTED，第 2 轮，零条发现）。没有行内评论、没有 issue 级评论、没有失败的检查，也没有持续失败的检查。 决定：不做代码改动。 自上次评估以来唯一的审查是自动审查器的一条信息性覆盖说明，并非发现项。其中两条"未审查"事项已对照工作流和本 PR 的 diff 核实：
反馈中没有任何内容指出缺陷、请求改动或提出问题，因此没有需要修复、拒绝或上报的事项。 Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 🧠 Handled by Qwen Code · model/模型 |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
Reviewed. Not reviewed: build-and-test — Integration Tests (CLI, No Sandbox) was skipped in CI and its suite did not run locally; the required no-AK integration gate (Test ubuntu-latest) is still pending at this commit and did not run locally.
中文说明
已审查。 未审查：build-and-test — Integration Tests (CLI, No Sandbox) was skipped in CI and its suite did not run locally; the required no-AK integration gate (Test ubuntu-latest) is still pending at this commit and did not run locally。
— qwen3.8-max via Qwen Code /review (v0.21.7)
Collaborator
|
🔀 Base updated: red check(s) [Post Coverage Comment (ubuntu-latest, 22.x)] pass on current main — merged current main via update-branch; CI will re-run. 中文说明🔀 已更新 base：红色检查 [Post Coverage Comment (ubuntu-latest, 22.x)] 在当前 main 上通过 —— 已通过 update-branch 合入当前 main，CI 将重新运行。 |
Collaborator
|
🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下： AutoFix round: no action takenNo review findings to address this round (the automated review ledger is empty, and there are no inline or issue-level comments). The only actionable item was the failed check Test (ubuntu-latest, Node 22.x). I could not reproduce any defect from this checkout: every runnable step of that CI job passes locally at the exact failing commit ( How the failed check was diagnosedThe CI logs for the failed run are not accessible from this environment (no GitHub credentials), so I reproduced the Test job step-by-step locally at the same commit:
One local unit-test run initially showed failures, but each was proven to be an artifact of this verification session's own environment, not of the tree:
None of the locally failing tests are touched by, or related to, this PR's diff (integration pool config, no-AK/SDK script flags, and the scripts/tests contract tests). Why no code change
Note on tree hygiene: during verification I ran the repository's 中文说明AutoFix 本轮：未做任何改动本轮没有需要处理的评审发现（自动评审 ledger 为空，也没有行内评论或 issue 级评论）。唯一可操作的事项是失败的检查 Test (ubuntu-latest, Node 22.x)。我无法从当前检出复现任何缺陷：该 CI 任务的每一个可运行步骤在失败的准确提交（ 失败检查的诊断过程该失败运行的 CI 日志在本环境不可访问（没有 GitHub 凭据），因此我在同一提交上逐步复现了 Test 任务的各个步骤：
有一次本地单测运行最初出现了失败，但每一项都被证实是本次验证会话自身环境的产物，而非代码树的问题：
本地失败的测试没有一个与本 PR 的 diff（integration 池配置、no-AK/SDK 脚本参数、scripts/tests 契约测试）有关。 为什么不做代码改动
代码树卫生说明：验证过程中我运行了仓库自带的 Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 🧠 Handled by Qwen Code · model/模型 |
Collaborator
Author
|
@qwen-code /triage |
Collaborator
|
Sandboxed verification: ✅ passed — merge-ready (agent verdict) - workflow run Ran the PR in an isolated, token-free container: A/B against the base build, mock-free harness assertions, targeted gates. Advisory evidence for human reviewers — not a review, an approval, or a CI check. Scripted assertions: 17 passed · 0 failed · 17 total 中文 — 判定：✅ 通过 · 可合入（agent 判定）沙箱验证在隔离、无凭证的容器中执行了该 PR 的代码（与 base 构建 A/B 对照、无 mock harness 断言、定向门禁）。仅作为评审证据，不构成评审、批准或 CI 检查。 脚本断言：17 通过 · 0 失败 · 17 总计 Verification reportPR 8689 verification —
|
| cell | tree | CLI override | cap | expected | peak | result |
|---|---|---|---|---|---|---|
| default integration run | head | none (config) | 4 | ≤ 4 | 4 | cap honored |
| default integration run | base | none (config) | 4 | > 4 (control) | 63 | limit inert |
| SDK suite | head | --poolOptions.forks.maxForks 2 |
2 | ≤ 2 | 2 | cap honored |
| SDK suite | base | --poolOptions.threads.maxThreads 2 |
2 | > 2 (control) | 63 | limit inert |
| no-AK file list | head | --poolOptions.forks.maxForks 2 |
2 | ≤ 2 | 2 | cap honored |
| no-AK file list | base | --maxWorkers 2 |
2 | measure | 2 | old flag honored |
Witness: evidence/01-ab-peak-workers-matrix.png (raw log logs/ab-matrix-run.log, per-cell vitest output in logs/cell-*.log). 12/12 scripted assertions in this matrix passed.
Notes on the cells: the base worktree has no build artifacts, so its test files fail fast (SDK import errors); the spawn peak is captured at scheduling time and is unaffected — base peaked at 63 workers for 12 files because tinypool pre-spawns minThreads (= default 63) workers, which is itself the resource waste the PR removes. The two base script cells therefore exited early (804 ms / 3.6 s, exit 1) with the peak already recorded; head cells ran the full 45 s window against real (fake-model) tests.
Secondary claims
- The new contract test is load-bearing and precise. On head it passes as part of the suite. Run against the OLD base config it fails on the intended assertion (
AssertionError: expected undefined to be 'forks',evidence/02-contract-test-fails-on-old-base-config.png). Against a finer mutant — head'spool: 'forks'present but the limits still underpoolOptions.threads(exactly this PR's bug class) — it fails onpoolOptions.forksbeingundefined(evidence/03-contract-test-fails-on-finer-mutant.png). The test pins both the pool and the options key, not just one of them. - The changed scripts enforce their caps — the two
≤ 2head cells above, driven with the exact flag strings from the newpackage.jsonscripts. - Gates.
npm run test:scriptson head: 937/937 individual tests pass, 49/50 files pass; the three PR-touched test files run green (25/25,logs/pr-tests-verbose.log).evidence/04-test-scripts-gate-head.png. A real integration file passes under the corrected config:fake-openai-server.test.ts12/12 with--poolOptions.forks.maxForks 2(evidence/05-head-fake-openai-green.png).
Findings
- Suggestion (pre-existing, partially declared): the same inert-limit pattern lives in four more configs.
scripts/tests/vitest.config.ts(threads8–16, nopool:) is named in the PR as out of scope; the identical pattern also exists, unnamed, inpackages/cli/vitest.config.ts(lines 167–170, threads 8–16),packages/core/vitest.config.ts(threads 8–16), andpackages/sdk-typescript/vitest.config.ts(threads 2–4). Under the default forks pool those limits are equally inert — on a 64-CPU runner those suites also get up to 63 workers instead of the intended bounds. Not a defect of this PR (the change is scoped to the integration config per the review comment it answers), but follow-up material; the description's residual-risk paragraph understates the sibling count by three. - Informational: the no-AK hunk is normalization, not a behavior fix. Measured on base: the old
--maxWorkers 2flag was honored (peak 2) because vitest 3.2.4's forks pool resolvespoolOptions.maxForks ?? config.maxWorkers ?? default. The PR's swap to--poolOptions.forks.maxForks 2is still correct hygiene (pool-specific, non-deprecated surface), but the description's "those limits were ignored" does not apply to this one script. - Environmental, not PR-caused: one gate file fails to load in this container.
scripts/tests/install-script.test.jsthrows at module scope whenCI=trueandzipis missing (this image shipsunzipbut notzip). The file is byte-identical between base and head and absent from the diff; all 937 individual tests still pass. Real GitHub runners shipzip, so this does not reproduce there.
Not covered
- Per-commit attribution: the checkout is depth-2 shallow (
git rev-list HEAD^1..HEAD^2returns 1 while the metadata lists 4 commits); only the aggregateHEAD^1..HEADdiff was verified. - Full integration suite to completion: no model credentials in this container and the suite is heavy; the concurrency cells plus the one green integration file stand in for it. The A/B observable (spawn cap) is orthogonal to test outcomes.
- docker/podman variants of the changed scripts (no container runtime here); Windows/macOS behavior.
- tsc on the new TS contract test:
npm run typecheckis per-workspace andscripts/testsis not a workspace — pre-existing convention (the directory already containscheck-i18n.test.ts); the file is validated by vitest transform + execution instead. - A/B of the package unit suites carrying the same mismatch (finding 1) — out of this PR's scope.
Methodology
Environment: 64-CPU Linux container, Node 22.23.2, vitest 3.2.4 (the repo's installed version). Base control = scratch git worktree at HEAD^1 (845d6cf77e), sharing the root node_modules — a clean control because the PR touches neither package-lock.json nor packages/**; base cells ran without build artifacts (files fail fast; spawn peaks captured at scheduling). Worker concurrency measured by /proc sampling (200 ms) of processes titled node (vitest N) ancestry-checked to the spawned vitest main pid; each cell capped at 45 s then SIGKILLed. Harnesses: ab-matrix.mjs (concurrency A/B), vacuity-checks.mjs (mutation/vacuity/gate assertions); results in results/*.json, raw logs in logs/, evidence PNGs rendered by scripts/verify-capture.mjs. Assertion counts are the sum of the two result files (12 + 5).
Evidence images
Harness scripts and raw logs are in the workflow run artifacts (7-day retention).
— Qwen Code · sandboxed verification
qwen-code-ci-bot
approved these changes
Aug 8, 2026
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
LGTM, looks ready to ship. ✅
Collaborator
|
🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下： Autofix review round — no action requiredThis round found no actionable feedback to address on PR #8689:
No code changes were made; the PR head is unchanged at 中文说明Autofix 审查轮次 —— 无需处理本轮在 PR #8689 上没有发现需要处理的反馈：
本轮未做任何代码改动；PR 头部提交保持不变，仍为 Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 🧠 Handled by Qwen Code · model/模型 |
yiliang114
approved these changes
Aug 8, 2026
yiliang114
left a comment
yiliang114
left a comment
Collaborator
There was a problem hiding this comment.
LGTM, no blockers. This fixes the integration worker limits actually being applied: the previous scripts used '--maxWorkers 2', which is a Jest flag vitest ignores, so the limit never took effect; switching to the forks pool with the correct vitest CLI arg '--poolOptions.forks.maxForks 2' (and poolOptions.forks {minForks:2,maxForks:4} in vitest.config.ts) makes it real. Forks also gives per-file process isolation, which suits integration tests that spawn daemons/subprocesses. Config and script changes are pinned by new tests (integration-vitest-config.test.ts asserts pool=forks + {2,4} and threads undefined; no-ak and package-scripts tests updated to the new flag). Test-infra only, no security impact. No P0/P1.
Collaborator
|
Released in v0.21.8. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does
This follow-up explicitly keeps the integration test suite on Vitest's
forkspool and moves its intended 2–4 worker limit to the matchingminForksandmaxForksoptions. The SDK integration scripts now apply their stricter two-worker override to the same pool.Configuration contract tests lock the selected pool, its default worker bounds, and the SDK script overrides so a future option mismatch cannot silently restore unbounded parallelism.
Why it's needed
Vitest 3.2.4 defaults to the
forkspool. The integration configuration and SDK script overrides usedthreads-specific options without switching the suite tothreads, so those limits were ignored. On larger runners, Vitest could therefore start substantially more integration workers than the configured maximum, increasing resource contention and making worker RPC timeouts more likely.Reviewer Test Plan
How to verify
Confirm that a normal integration run resolves to the
forkspool with a minimum of two and maximum of four workers, while both SDK-only integration commands cap the same pool at two workers. Confirm that changing the configuration back to thread-specific options causes the configuration contract test to fail.The new contract test failed against the previous configuration because the selected pool was implicit and the limits were stored under
threads; it passes after this change. A lightweight integration file also passes under the corrected configuration, and project build, lint, and typecheck complete successfully.Evidence (Before & After)
N/A — test runner configuration only; no user-visible UI change.
Tested on
Environment (optional)
Node.js 22.22.2, Vitest 3.2.4, no sandbox.
Risk & Scope
scripts/tests/vitest.config.tshas the same pre-existing default-pool mismatch and can still report worker RPC timeouts in the full scripts suite; this PR is limited to the integration configuration identified in the review comment.Linked Issues
Follow-up to #8685 and review comment #8685 (comment).
中文说明
本 PR 做了什么
这个 follow-up 显式保持 integration test suite 使用 Vitest 的
forkspool，并将原本计划的 2–4 worker 限制迁移到匹配的minForks和maxForks配置。SDK integration 脚本也改为对同一个 pool 应用更严格的两个 worker 覆盖。配置契约测试锁定选用的 pool、默认 worker 上下限和 SDK 脚本覆盖，避免未来再次因 option 与 pool 不匹配而静默恢复无上限并发。
为什么需要
Vitest 3.2.4 默认使用
forkspool。integration 配置和 SDK 脚本覆盖使用了threads专用选项，却没有把 suite 切换到threads，因此这些限制会被忽略。在较大的 runner 上，Vitest 可能启动明显多于配置上限的 integration workers，增加资源争用并提高 worker RPC timeout 的发生概率。Reviewer Test Plan
如何验证
确认普通 integration run 会解析为
forkspool，最少两个、最多四个 worker；两个 SDK-only integration 命令会把同一个 pool 限制为两个 worker。确认将配置改回 threads 专用选项时，配置契约测试会失败。新契约测试在旧配置上会失败，因为选用的 pool 是隐式的，而限制存放在
threads下；本次修改后测试通过。轻量 integration 文件也在修正后的配置下通过，项目 build、lint 和 typecheck 均成功完成。证据（Before & After）
N/A——仅测试运行器配置变更，没有用户可见 UI 变化。
测试平台
环境（可选）
Node.js 22.22.2、Vitest 3.2.4、无 sandbox。
风险与范围
scripts/tests/vitest.config.ts存在相同的既有默认 pool mismatch，完整 scripts suite 仍可能报告 worker RPC timeout；本 PR 仅处理 review 评论指出的 integration 配置。关联问题
#8685 的 follow-up，以及 review 评论 https://github.com/QwenLM/qwen-code/pull/8685#issuecomment-5216905689。