Skip to content

fix(test): raise the ACP initialize budget for inline E2E daemon spawns (#11034) #11041

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
wenshao merged 1 commit into from
Sep 5, 2026
Merged

fix(test): raise the ACP initialize budget for inline E2E daemon spawns (#11034) #11041

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions integration-tests/cli/qwen-serve-channel-workers.test.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,6 +28,10 @@ const REPO_ROOT = path.resolve(__dirname, '../..');
const CLI_BIN =
process.env['TEST_CLI_PATH'] ?? path.join(REPO_ROOT, 'dist', 'cli.js');
const TOKEN = 'multi-workspace-channel-test-token';
// The 10s production handshake budget is a desktop budget, not a shared-runner
// one: macOS E2E shards died on it in #11030 and reddened again in #11034.
// Match qwen-serve-routes.test.ts.
const ACP_INITIALIZE_TIMEOUT_MS = 60_000;
Comment on lines +33 to +34

@qwen-code-dev-bot qwen-code-dev-bot Sep 4, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done — ran this suite against the branch as asked: 4/4 tests pass against the bundled CLI (npm run build && npm run bundle, then QWEN_SANDBOX=false vitest run --root ./integration-tests cli/qwen-serve-channel-workers.test.ts). All three changed suites together: 3 files / 17 tests passed.

That also witnesses the four --initialize-timeout-ms pairs here end to end rather than by inspection: runQwenServe rejects a non-positive or non-integer value (packages/cli/src/serve/run-qwen-serve.ts:4120-4126), so a malformed pair would abort daemon boot and fail every test in the suite.

One premise correction: this file genuinely has no pull_request-event gate — integration_cli is merge_group-only (ci.yml:1980) and e2e.yml has no pull_request trigger — but that split is deliberate. integration_no_ak's own comment records that the merge_group-only skip once led the review bot to rule a changed integration test "never ran" (#9895 round 15), which is why that gate got its own check name. Note also that qwen-serve-streaming.test.ts, the third changed suite, is in the no-AK PR gate and had already passed on this head (SUCCESS, 18:55:00 → 19:17:39).

Open question for a maintainer — the reason this thread stays open: should qwen-serve-channel-workers.test.ts and qwen-serve-client-mcp.test.ts join the curated no-AK PR gate? Both use fake OpenAI servers with OPENAI_API_KEY: 'fake-key', so they need no credentials, but they are daemon-heavy — this suite alone took 72s of that job's 20-minute step budget. That is a CI-minutes tradeoff in .github/workflows/ci.yml, outside this PR's footprint and outside this loop's modification boundary, so I am surfacing it rather than deciding it.

中文说明

已按要求针对分支运行该套件：4/4 测试通过（先 npm run build && npm run bundle，再 QWEN_SANDBOX=false vitest run --root ./integration-tests cli/qwen-serve-channel-workers.test.ts），基于打包后的 CLI。三个被改套件合计：3 个文件 / 17 个测试全部通过。

这也用端到端执行而非阅读代码的方式，佐证了此处四对 --initialize-timeout-ms 参数：runQwenServe 会拒绝非正数或非整数值（packages/cli/src/serve/run-qwen-serve.ts:4120-4126），所以只要有一对参数格式错误，守护进程就会启动失败并使该套件的每个测试都失败。

对前提的一处更正：这个文件确实没有 pull_request 事件的门禁 —— integration_cli 仅在 merge_group 上运行（ci.yml:1980），e2e.yml 也没有 pull_request 触发器 —— 但这个划分是有意为之。integration_no_ak 自己的注释就记录了：正是这个 merge_group-only 的 skip 曾让审查机器人判定一个被改的集成测试"从未运行过"（#9895 第 15 轮），这也是该门禁获得独立检查名的原因。另外请注意，第三个被改套件 qwen-serve-streaming.test.ts 确实在 no-AK 的 PR 门禁里，并且在这个 head 上已经通过（SUCCESS，18:55:00 → 19:17:39）。

**留给维护者的开放问题 —— 也是这个讨论串保持开放的原因：**是否应把 qwen-serve-channel-workers.test.ts 和 qwen-serve-client-mcp.test.ts 加入精心挑选的 no-AK PR 门禁？两者都使用 OPENAI_API_KEY: 'fake-key' 的假 OpenAI 服务器，因此不需要凭据，但它们对守护进程的依赖较重 —— 仅这个套件就占用了该任务 20 分钟步骤预算中的 72 秒。这属于 .github/workflows/ci.yml 中的 CI 时长取舍，超出本 PR 的 footprint，也超出本自动修复流程允许修改的边界，所以我只把它提出来而不擅自决定。


let daemon: ChildProcess | undefined;
let primaryServer: MockServerHandle | undefined;
Expand Down Expand Up @@ -292,6 +296,8 @@ describe('qwen serve multi-workspace channel workers', () => {
TOKEN,
'--workspace',
workspace,
'--initialize-timeout-ms',
String(ACP_INITIALIZE_TIMEOUT_MS),
],
{ stdio: ['ignore', 'pipe', 'pipe'], env },
);
Expand Down Expand Up @@ -472,6 +478,8 @@ describe('qwen serve multi-workspace channel workers', () => {
TOKEN,
'--workspace',
workspace,
'--initialize-timeout-ms',
String(ACP_INITIALIZE_TIMEOUT_MS),
],
{
stdio: ['ignore', 'pipe', 'pipe'],
Expand Down Expand Up @@ -600,6 +608,8 @@ describe('qwen serve multi-workspace channel workers', () => {
TOKEN,
'--workspace',
workspace,
'--initialize-timeout-ms',
String(ACP_INITIALIZE_TIMEOUT_MS),
],
{
stdio: ['ignore', 'pipe', 'pipe'],
Expand Down Expand Up @@ -735,6 +745,8 @@ describe('qwen serve multi-workspace channel workers', () => {
'primary',
'--channel',
'secondary',
'--initialize-timeout-ms',
String(ACP_INITIALIZE_TIMEOUT_MS),
],
{
stdio: ['ignore', 'pipe', 'pipe'],
Expand Down
Loading
Loading