feat(serve): make ACP initialize handshake timeout configurable - #7246
Conversation
Add --initialize-timeout-ms CLI flag to qwen serve, wiring it through to BridgeOptions.initializeTimeoutMs. The ACP initialize handshake defaults to 10 s (DEFAULT_INIT_TIMEOUT_MS); containerized deployments where the child process needs longer can now raise the ceiling without patching the source. Fixes #7244
…idge Add the missing NUMBER_OPTIONS entry in fast-path.ts and forward initializeTimeoutMs in the server.ts inline createAcpSessionBridge call so the direct-embed / test path also respects the flag.
|
Thanks for the PR! Template looks good ✓ Problem: real and well-specified. Linked issue #7244 describes containerized deployments where cold starts exceed the hardcoded 10 s ACP initialize timeout. The issue was triaged as Direction: aligned. Size: cross-package (channels + cli), 220 additions / 2 deletions. Well under thresholds — no escalation needed. Approach: the However, the diff also carries unrelated changes to Moving on to code review. 🔍 中文说明感谢贡献！ 模板完整 ✓ 问题：真实且描述充分。关联 issue #7244 描述了容器化部署冷启动超过硬编码 10 秒 ACP 初始化超时的场景。Issue 已被标记为 方向：一致。 规模：跨包（channels + cli），220 行新增 / 2 行删除。远低于阈值——无需升级。 方案： 但 diff 还夹带了无关改动： 进入代码审查 🔍 — Qwen Code · qwen3.7-max Reviewed at |
Code ReviewIndependent proposal: given the existing Findings: The The No critical blockers. No AGENTS.md violations. Unit TestsAll 6 new tests pass: Real-Scenario TestingNo user-visible TUI change — this is a Validation rejects invalid values: Valid value starts the server normally: Help text shows the flag: 中文说明代码审查独立方案： 鉴于 发现：
无关键阻塞项。无 AGENTS.md 违规。 单元测试6 个新测试全部通过。 真实场景测试无用户可见 TUI 变更——这是 — Qwen Code · qwen3.7-max Reviewed at |
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. |
|
Confidence: 4/5 — clean, mechanical wiring that follows established patterns exactly; only non-blocking nit is the unrelated This is a textbook "wire an existing API to a user-facing flag" PR. The The Approving. ✅ 中文说明置信度：4/5 — 干净、机械化的接线，完全遵循现有模式；唯一的非阻塞建议是无关的 这是一个教科书式的"将现有 API 接到用户可见 flag"的 PR。
批准。✅ — Qwen Code · qwen3.7-max Reviewed at |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
LGTM, looks ready to ship. ✅
🩺 serve daemon A/BBuilt the PR base vs this PR head ✅ No response changes against the PR base across 4 scenario(s). — Qwen Code · serve A/B |
Local real-environment verification — REQUEST CHANGESTested exact head: The intended feature works in the normal case, but I do not recommend merging this exact head yet. Two deterministic blockers were found. Environment and harness
This exercises built CLI parsing and the fast path, the daemon listener/runtime and preheat path, child process spawning, stdio NDJSON ACP initialization, the bridge timer, and HTTP session creation. It is a full local process/HTTP E2E for this wiring, not a mocked unit test. A/B result: intended behavior is confirmed
This proves that the new flag reaches the real ACP initialize timer and solves the reported cold-start scenario for a valid value. Blocker 1: timer overflow turns a huge accepted timeout into about 1 ms
The real The validation should reject values above the JavaScript timer ceiling, 2,147,483,647 ms. The existing Blocker 2: deterministic fast-path test failureLocal result:
The remote Ubuntu Node 22 job independently reports the same failure: 1 failed, 14,203 passed, 21 skipped. The remote Serve A/B job passed. Other verification
Scope and merge noteThis PR is stacked on commit RecommendationREQUEST CHANGES. The direction is correct and the 15-second real-environment behavior is validated, but do not merge this exact head until:
中文测试报告本地真实环境验证 — 建议修改后再合并测试的精确提交： 正常取值下，目标功能确实有效，但不建议合并当前 head。测试发现两个可稳定复现的阻断项。 环境与测试装置
该测试覆盖构建后 CLI 参数解析和 fast path、daemon listener/runtime 与 preheat、子进程拉起、stdio NDJSON ACP 初始化、bridge 定时器及 HTTP session 创建。这是完整的本地进程/HTTP E2E，不是 mock 单元测试。 A/B 结果：目标行为得到确认
这证明新参数确实传递到了真实 ACP initialize 定时器，合法取值下能够解决所报告的冷启动问题。 阻断项 1：定时器溢出会把很大的合法输入变成约 1 ms
真实 校验应拒绝超过 JavaScript 定时器上限 2,147,483,647 ms 的值。现有用于 阻断项 2：fast-path 测试稳定失败本地结果：
远端 Ubuntu Node 22 任务独立复现了同一失败：1 failed、14,203 passed、21 skipped。远端 Serve A/B 任务通过。 其他验证
范围与合并说明该 PR 基于仍处于 open 状态的 PR #7223 的提交 建议建议修改后再合并。 方向正确，15 秒超时的真实环境行为也已验证，但当前 head 应在以下事项完成后再合并：
|
jifeng
left a comment
jifeng
left a comment
There was a problem hiding this comment.
Requesting changes for two deterministic stability problems found in real-environment validation. The normal 15-second path works, but the current upper-bound handling can collapse a large timeout to 1 ms, and the fast-path contract suite is red.
| if ( | ||
| !Number.isFinite(opts.initializeTimeoutMs) || | ||
| !Number.isInteger(opts.initializeTimeoutMs) || | ||
| opts.initializeTimeoutMs <= 0 |
There was a problem hiding this comment.
[P1] Reject values above the Node timer ceiling
This positive-integer check accepts 2147483648, but setTimeout cannot represent that delay. In the built CLI E2E, Node emitted TimeoutOverflowWarning, reduced the timer to 1 ms, and POST /session failed in 84 ms while claiming a 2147483648 ms timeout. Please validate initializeTimeoutMs <= 2_147_483_647 using the existing timer-range helper/pattern and add an upper-bound regression test. Otherwise a stability knob can produce the opposite behavior under an operator typo or generated configuration.
| ['promptDeadlineMs', 'prompt-deadline-ms'], | ||
| ['writerIdleTimeoutMs', 'writer-idle-timeout-ms'], | ||
| ['channelIdleTimeoutMs', 'channel-idle-timeout-ms'], | ||
| ['initializeTimeoutMs', 'initialize-timeout-ms'], |
There was a problem hiding this comment.
[P1] Update the fast-path option contract fixture
Adding this entry without adding initialize-timeout-ms to sampleArgvByOption makes src/serve/fast-path.test.ts fail deterministically at line 663 (1 failed, 67 passed locally). The Ubuntu Node 22 CI job reports the same failure (1 failed, 14,203 passed). Please add the representative argv case and keep this contract test green so future parser drift remains detectable.
| ['promptDeadlineMs', 'prompt-deadline-ms'], | ||
| ['writerIdleTimeoutMs', 'writer-idle-timeout-ms'], | ||
| ['channelIdleTimeoutMs', 'channel-idle-timeout-ms'], | ||
| ['initializeTimeoutMs', 'initialize-timeout-ms'], |
There was a problem hiding this comment.
[Critical] Adding initialize-timeout-ms to NUMBER_OPTIONS breaks the exhaustiveness test in fast-path.test.ts ("handles every yargs serve long option or explicitly falls back"): the test's sampleArgvByOption map was not updated, so npm test --workspace=packages/cli fails — the received option list includes initialize-timeout-ms but the expected list does not. — Failure scenario: the CLI test suite exits non-zero on this branch (this is what the failing Test (ubuntu-latest, Node 22.x) CI check is hitting), and fast-path parsing of --initialize-timeout-ms has no coverage for numeric coercion/fallback. Fix in fast-path.test.ts alongside the other *-ms entries:
['initialize-timeout-ms', ['--initialize-timeout-ms', '10000']],— qwen3.8-max-preview via Qwen Code /review
| !Number.isFinite(opts.initializeTimeoutMs) || | ||
| !Number.isInteger(opts.initializeTimeoutMs) || | ||
| opts.initializeTimeoutMs <= 0 |
There was a problem hiding this comment.
[Suggestion] This inlined predicate is the exact logical negation of the existing isPositiveIntegerMs helper (line 246); the sibling promptDeadlineMs and writerIdleTimeoutMs validations call that helper directly. — Concrete cost: if the predicate ever changes (e.g. an upper-bound check), this inlined copy is missed and initializeTimeoutMs silently diverges from the other positive-integer timeouts.
| !Number.isFinite(opts.initializeTimeoutMs) || | |
| !Number.isInteger(opts.initializeTimeoutMs) || | |
| opts.initializeTimeoutMs <= 0 | |
| !isPositiveIntegerMs(opts.initializeTimeoutMs) |
— qwen3.8-max-preview via Qwen Code /review
| }); | ||
| }); | ||
|
|
||
| describe('runQwenServe initializeTimeoutMs validation', () => { |
There was a problem hiding this comment.
[Suggestion] The two rejection tests cover 0 (non-positive) and NaN (non-finite), but nothing exercises the !Number.isInteger guard at run-qwen-serve.ts:2399. — Concrete cost: if that guard is accidentally removed in a future refactor, fractional values (e.g. 1.5) are silently accepted, contradicting the documented "Must be a positive integer" contract. Add a case such as:
it('rejects a non-integer initializeTimeoutMs', async () => {
// ...same setup as the other two cases...
await expect(
runQwenServe(
{ ...opts, initializeTimeoutMs: 1.5 },
{ bridge: fakeBridge },
),
).rejects.toThrow(/initializeTimeoutMs/);
});— qwen3.8-max-preview via Qwen Code /review
| ); | ||
| } | ||
| } | ||
| if (opts.initializeTimeoutMs !== undefined) { |
There was a problem hiding this comment.
[Suggestion] The validation admits any positive finite integer, including values > 2³¹−1 (≈24.8 days). Node's setTimeout treats delays above 2³¹−1 as ~1 ms (32-bit overflow), so withTimeout() in bridge.ts would fire the initialize timer almost immediately. — Failure scenario: qwen serve --initialize-timeout-ms 3000000000 passes all three checks, reaches setTimeout(…, 3000000000), fires at ~1 ms, and every ACP child's initialize handshake fails with BridgeTimeoutError — the opposite of the operator's intent, and hard to triage because the error quotes the huge value as if it were honored. The sibling permissionResponseTimeoutMs is clamped to 2_147_483_647 in bridge.ts and promptDeadlineMs uses assertTimerDelayInRange; initializeTimeoutMs has neither. Suggested fix: reject opts.initializeTimeoutMs > 2_147_483_647 here, or clamp in bridge.ts alongside the existing permissionTimeoutMs clamp.
— qwen3.8-max-preview via Qwen Code /review
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
— qwen3.7-max via Qwen Code /review
|
🤖 Could not address the latest feedback automatically (round 1/5). A human should take over this PR. What I found before stopping: Autofix review response — PR #7246Addressed both deterministic blockers from real-environment validation plus the actionable automated-reviewer suggestions. One additive commit: Feedback points and decisions1. [Required / P1] Timer overflow turns a huge accepted timeout into ~1 ms (
2. [Required / P1] Deterministic fast-path contract test failure (
3. [Suggestion] Use the
Run log: https://github.com/QwenLM/qwen-code/actions/runs/29727867136 🧠 Handled by Qwen Code · model/模型 |
|
🤖 Could not address the latest feedback automatically (round 2/5). A human should take over this PR. What I found before stopping: Review feedback addressedFailed check:
|
Local real-environment re-verification at head
|
| Case | ACP child stalls initialize |
Result | Elapsed |
|---|---|---|---|
| A — no flag (built-in 10 000 ms) | 14 000 ms | HTTP 500 AcpSessionBridge initialize timed out after 10000ms |
10 177 ms |
B — --initialize-timeout-ms 30000 |
14 000 ms | HTTP 200, session created | 14 220 ms |
| C — same flag, merge-base build | 14 000 ms | Unknown arguments: initialize-timeout-ms, initializeTimeoutMs, exit 1 |
— |
C is the counterfactual: rebuilt with the five CLI source files reverted to 102c6921, the flag does not exist. So the A→B delta is attributable to this PR and nothing else. The flag reaches the real withTimeout(connection.initialize(...), initTimeoutMs, 'initialize') timer at acp-bridge/src/bridge.ts:2156. Issue #7244's cold-start scenario is solved for sane values.
Validation matrix — all rejected at boot with exit 1, message Invalid initializeTimeoutMs: <v>. Must be a positive integer (milliseconds).
| Value | Parsed via | Outcome |
|---|---|---|
0 |
fast path | rejected ✅ |
-5 |
yargs fallback | rejected ✅ |
1.5 |
fast path | rejected ✅ |
abc |
yargs fallback | rejected (NaN) ✅ |
30000 |
fast path | accepted, daemon listens ✅ |
Worth noting both the fast path and the yargs fallback converge on the same error — the cea08fb5 follow-up that wired fast-path.ts was necessary and is correct.
2. Blocker 1 (still open): fast-path.test.ts fails deterministically
packages/cli $ npx vitest run src/serve/fast-path.test.ts
@ head 94c51d5 → 1 failed | 67 passed (68)
@ merge-base 102c6921 → 68 passed (68)
handles every yargs serve long option or explicitly falls back (fast-path.test.ts:663) is an exhaustiveness contract: every yargs long option must have a sample argv. initialize-timeout-ms was added to the parser and to NUMBER_OPTIONS but not to sampleArgvByOption.
This is not a local-only artifact — Test (ubuntu-latest, Node 22.x) on this PR is red right now (job 88309403006, failed at Run tests and generate reports).
Verified fix — one line, restores 68/68:
['channel-idle-timeout-ms', ['--channel-idle-timeout-ms', '1000']],
+ ['initialize-timeout-ms', ['--initialize-timeout-ms', '30000']],With that line the parse half of the test also passes, i.e. it confirms the fast path really handles the flag rather than falling back.
3. Blocker 2 (still open): no 2^31-1 upper bound — a huge timeout inverts to ~0
| Flag value | Intended wait | Actual wait | Result |
|---|---|---|---|
2147483647 |
24.8 days | 3 184 ms (waits out the 3 s stall) | HTTP 200 ✅ |
2147483648 |
24.8 days | 167 ms | HTTP 500 initialize timed out after 2147483648ms |
4000000000 |
46 days | 175 ms | HTTP 500 |
Node clamps setTimeout delays above 2^31-1 to 1 ms (TimeoutOverflowWarning). An operator who picks a deliberately enormous value to mean "effectively never time out" gets the exact opposite: every session creation fails immediately, while the error text confidently reports the huge number. Silent inversion, no warning in the daemon log.
This is precisely the failure mode the sibling option already guards against, with a comment saying so — acp-bridge/src/bridge.ts:1317:
// Clamp to 2^31-1: Node treats setTimeout delays larger than
// this as 1ms (TimeoutOverflowWarning), which would make a
// huge "effectively never" timeout cancel prompts almost
// immediately — the opposite of intent.
Math.min(permissionTimeoutRaw, 2_147_483_647)The PR description says the validation "mirrors the existing permissionResponseTimeoutMs and channelIdleTimeoutMs patterns" — it mirrors the lower bound but not the upper one.
Verified fix (rebuilt + re-ran the same matrix): adding || opts.initializeTimeoutMs > 2_147_483_647 to the new check makes 2147483648 fail loudly at boot with exit 1, while 2147483647 still works normally. assertTimerDelayInRange (already used for promptDeadlineMs) is the more idiomatic vehicle. Please add the upper-bound regression test alongside.
4. Stacked #7223 commit — measured behavioral scope, not just a tidiness issue
@jifeng flagged that 59150c5 ("exclude discrete messages from replies", from still-open #7223) rides along in this diff. Agreed on the split — and I'd add that the change is larger in effect than its own test suggests. The PR's new test only covers a background_notification display banner (Background agent "Explore" completed.), which is plausibly noise. But qwenDiscreteMessage: true is set by three distinct producers, and textChunk is the only delivery path into a channel reply — there is no separate discrete-bubble surface in a chat channel the way there is in web-shell / the VS Code companion.
Driving the built channels/base AcpBridge with the four _meta shapes qwen actually emits:
| Producer | Content | Reaches channel reply? |
|---|---|---|
| (none) | ordinary assistant text | YES |
background_notification — Session.ts:5010 |
display banner | dropped |
background_notification_response — Session.ts:5029 |
model-generated prose | dropped |
todo_stop_guard — Session.ts:3411 |
operator warning about unfinished todos | dropped |
slash_command — MessageEmitter.ts:152 |
slash output (no discrete flag) | YES (unaffected) ✅ |
#emitBackgroundNotificationResponse carries responseText straight from the model stream — real content a channel user would presumably want. Suppressing the banner and suppressing the model's answer are different decisions; the current guard makes both. Not a blocker for this PR (it belongs to #7223), which is exactly why it should be split out and settled there on its own merits.
5. The autofix commit referenced above never landed
The bot comment (2026-07-20 08:51Z) reports both blockers "Fixed" in additive commit f63d77a5d. That commit is not reachable from this branch:
$ git cat-file -t f63d77a5d
fatal: Not a valid object name f63d77a5d
$ git log --oneline --no-merges 102c6921..94c51d50b
cea08fb57 fix(serve): wire initializeTimeoutMs to fast-path parser and embed bridge
594126019 feat(serve): make ACP initialize handshake timeout configurable
59150c503 fix(channels): exclude discrete messages from replies
Consistent with that comment's own header ("Could not address the latest feedback automatically … A human should take over") and its acted=false marker. Flagging it so the "Fixed" text isn't taken at face value when triaging.
6. Nice-to-have: the flag is broader than its name and help text
initTimeoutMs has 26 use sites in acp-bridge/src/bridge.ts; exactly one is the initialize handshake. The rest are newSession, sessionSource, sessionParent, approval-mode, model-switch, workspace-status polling, transcript, and ~20 other ext-method deadlines. Measured, not just read:
Child stalls session/new 14 s |
Flag | Result |
|---|---|---|
| yes | (none) | HTTP 500 AcpSessionBridge newSession timed out after 10000ms @ 10 183 ms |
| yes | --initialize-timeout-ms 30000 |
HTTP 200 @ 14 197 ms |
For the cold-container use case this is arguably desirable — a cold child is slow at newSession too. But --initialize-timeout-ms 300000 also means a wedged child can hold a workspace-status poll for five minutes, and the help text (ACP initialize handshake timeout (ms)) doesn't hint at that. Suggest widening the description to something like "ACP child request timeout, including the initialize handshake (ms)".
7. Nice-to-have: docs not updated
Every sibling serve timeout flag is documented; this one is in none of the four files that carry those tables:
docs/developers/daemon/17-configuration.mddocs/developers/daemon/20-quickstart-operations.mddocs/developers/daemon/02-serve-runtime.mddocs/users/qwen-serve.md
What is clean
npm run typecheck— passes (exit 0, all workspaces)eslinton all 11 changed files — cleanpackages/channels/base— 82/82 passserve.test.ts+run-qwen-serve.test.ts(the PR's own 4 new tests) — passServe A/Bandweb-shell E2E SmokeCI jobs — pass
Recommendation
REQUEST CHANGES — same three items as @jifeng's review, all still open at 94c51d5, plus two non-blocking suggestions:
- Blocking — add the
initialize-timeout-msentry tosampleArgvByOptionso CI goes green. - Blocking — bound
initializeTimeoutMsat2_147_483_647(preferassertTimerDelayInRange) + upper-bound regression test. - Blocking — rebase or split so
59150c5(fix(channels): exclude discrete ACP messages from replies #7223) leaves this diff; the timeout change should be independently reviewable and revertible. - Non-blocking — document the flag alongside its siblings.
- Non-blocking — reword the help text to reflect that it governs ACP child requests generally, not only
initialize.
The underlying change is well-targeted and the wiring is correct, including the fast-path follow-up. With 1–3 addressed I'd be happy to see this merged.
中文测试报告
在 head 94c51d5 上的本地真实环境复验 — 建议修改后再合并
在 main 合并进来之后，在 Linux 上做了一次独立复验。结论：功能本身确实有效并且可以被证明有效，但 @jifeng 针对 cea08fb5 提出的两个阻断项在当前 head 上仍然存在。 上面的 autofix 评论声称已在提交 f63d77a5d 中修复 —— 该提交并不在本分支上（见第 5 节）。
测试的精确 head： 94c51d50b（main 合入 feat/serve-initialize-timeout-ms 的 merge commit），merge-base 为 102c6921。
环境与测试装置
- Linux x86_64（Debian，内核 6.12.63），Node.js 22.22.2
- 根目录
npm run build+npm run bundle，随后运行真实的node dist/cli.js serve—— 不是 mock 单元测试 QWEN_CLI_ENTRY指向一个最小化的原始 NDJSON 假 ACP 子进程，可按需延迟initialize（以及单独延迟session/new）的响应。不涉及模型、网络和凭证，因此测量结果只反映：CLI 解析 → fast path → daemon 启动 → 子进程拉起 → stdio ACP 握手 → bridge 定时器 →POST /session- 每次运行使用隔离的
HOME/QWEN_HOME/ workspace，daemon 各自绑定独立的临时端口
这套装置与 @jifeng 的有意做得不同（原始 NDJSON vs @agentclientprotocol/sdk，Linux vs macOS），因此两份报告的一致性属于独立互证，而非简单重复。
1. 功能有效 — A/B 已确认
| 场景 | 子进程延迟 initialize |
结果 | 耗时 |
|---|---|---|---|
| A — 无参数（内置 10 000 ms） | 14 000 ms | HTTP 500 AcpSessionBridge initialize timed out after 10000ms |
10 177 ms |
B — --initialize-timeout-ms 30000 |
14 000 ms | HTTP 200，session 创建成功 | 14 220 ms |
| C — 相同参数，merge-base 构建 | 14 000 ms | Unknown arguments: initialize-timeout-ms, initializeTimeoutMs，退出码 1 |
— |
C 是反事实对照：把 5 个 CLI 源文件回退到 102c6921 后重新构建，该参数并不存在。因此 A→B 的差异确实由本 PR 产生。参数真正到达了 acp-bridge/src/bridge.ts:2156 的 withTimeout(connection.initialize(...), initTimeoutMs, 'initialize')。在合理取值下，#7244 的冷启动问题已被解决。
校验矩阵 —— 以下取值均在启动阶段以退出码 1 被拒绝，错误信息为 Invalid initializeTimeoutMs: <v>. Must be a positive integer (milliseconds).
| 取值 | 解析路径 | 结果 |
|---|---|---|
0 |
fast path | 拒绝 ✅ |
-5 |
yargs 回退 | 拒绝 ✅ |
1.5 |
fast path | 拒绝 ✅ |
abc |
yargs 回退 | 拒绝（NaN）✅ |
30000 |
fast path | 接受，daemon 正常监听 ✅ |
值得一提的是 fast path 与 yargs 回退最终收敛到同一条错误信息 —— cea08fb5 补写 fast-path.ts 的那次跟进是必要且正确的。
2. 阻断项 1（仍未修复）：fast-path.test.ts 稳定失败
packages/cli $ npx vitest run src/serve/fast-path.test.ts
head 94c51d5 → 1 failed | 67 passed (68)
merge-base 102c6921 → 68 passed (68)
handles every yargs serve long option or explicitly falls back（fast-path.test.ts:663）是一个穷尽性契约测试：每个 yargs 长参数都必须有对应的样例 argv。initialize-timeout-ms 加进了 parser 和 NUMBER_OPTIONS，但没有加进 sampleArgvByOption。
这不是本地环境问题 —— 本 PR 的 Test (ubuntu-latest, Node 22.x) 当前就是红的（job 88309403006，失败在 Run tests and generate reports 步骤）。
已验证的修复（一行，恢复 68/68）：
['channel-idle-timeout-ms', ['--channel-idle-timeout-ms', '1000']],
+ ['initialize-timeout-ms', ['--initialize-timeout-ms', '30000']],加上这行之后，该测试的解析部分也通过，从而进一步确认 fast path 确实处理了这个参数，而不是回退到 yargs。
3. 阻断项 2（仍未修复）：缺少 2^31-1 上界 —— 极大超时会反转成约 0
| 参数值 | 期望等待 | 实际等待 | 结果 |
|---|---|---|---|
2147483647 |
24.8 天 | 3 184 ms（成功等过 3 s 延迟） | HTTP 200 ✅ |
2147483648 |
24.8 天 | 167 ms | HTTP 500 initialize timed out after 2147483648ms |
4000000000 |
46 天 | 175 ms | HTTP 500 |
Node 会把超过 2^31-1 的 setTimeout 延迟压缩为 1 ms（TimeoutOverflowWarning）。运维人员如果特意填一个极大值来表达"基本上永不超时"，得到的是完全相反的结果：每次创建 session 都立即失败，而错误信息还煞有介事地报出那个巨大的数值。属于静默反转，daemon 日志中没有任何告警。
这正是同类参数已经防住的失败模式，acp-bridge/src/bridge.ts:1317 甚至有注释说明：
// Clamp to 2^31-1: Node treats setTimeout delays larger than
// this as 1ms (TimeoutOverflowWarning), which would make a
// huge "effectively never" timeout cancel prompts almost
// immediately — the opposite of intent.
Math.min(permissionTimeoutRaw, 2_147_483_647)PR 描述称新校验"与现有 permissionResponseTimeoutMs 和 channelIdleTimeoutMs 模式一致" —— 它对齐了下界，但没有对齐上界。
已验证的修复（重新构建并跑了同一组矩阵）：在新校验中加入 || opts.initializeTimeoutMs > 2_147_483_647 后，2147483648 会在启动阶段以退出码 1 明确失败，而 2147483647 仍然正常工作。更符合现有风格的做法是复用 assertTimerDelayInRange（promptDeadlineMs 已在用）。请一并补上上界回归测试。
4. 夹带的 #7223 提交 —— 实测的行为影响范围，不只是整洁性问题
@jifeng 已指出 59150c5（来自仍未合并的 #7223）夹带在本 diff 中。我同意应当拆分 —— 并且想补充：这个改动的实际影响比它自带的测试所体现的更大。PR 新增的测试只覆盖了 background_notification 展示横幅（Background agent "Explore" completed.），那确实更像噪音。但 qwenDiscreteMessage: true 由三个不同的生产者设置，而 textChunk 是进入 channel 回复的唯一通路 —— 聊天 channel 里并没有 web-shell / VS Code companion 那样独立的"离散气泡"承载面。
用 qwen 实际会发出的四种 _meta 形态驱动构建产物中的 channels/base AcpBridge：
| 生产者 | 内容 | 能否进入 channel 回复？ |
|---|---|---|
| （无） | 普通助手文本 | 能 |
background_notification — Session.ts:5010 |
展示横幅 | 被丢弃 |
background_notification_response — Session.ts:5029 |
模型生成的正文 | 被丢弃 |
todo_stop_guard — Session.ts:3411 |
关于未完成 todo 的运维告警 | 被丢弃 |
slash_command — MessageEmitter.ts:152 |
slash 命令输出（无离散标记） | 能（未受影响）✅ |
#emitBackgroundNotificationResponse 携带的 responseText 直接来自模型输出流 —— 这是 channel 用户大概率希望看到的真实内容。"抑制横幅"和"抑制模型的回答"是两个不同的决定，当前的判断条件把两者一起做了。这对本 PR 不构成阻断（它属于 #7223）—— 而这恰恰说明它应该被拆出去，在 #7223 里按其自身价值单独讨论。
5. 上面提到的 autofix 提交从未落地
bot 评论（2026-07-20 08:51Z）称两个阻断项已在增量提交 f63d77a5d 中"Fixed"。该提交在本分支上不可达：
$ git cat-file -t f63d77a5d
fatal: Not a valid object name f63d77a5d
$ git log --oneline --no-merges 102c6921..94c51d50b
cea08fb57 fix(serve): wire initializeTimeoutMs to fast-path parser and embed bridge
594126019 feat(serve): make ACP initialize handshake timeout configurable
59150c503 fix(channels): exclude discrete messages from replies
这与该评论自身的开头（"Could not address the latest feedback automatically … A human should take over"）以及 acted=false 标记是一致的。在此指出，以免后续 triage 时把 "Fixed" 字样当真。
6. 建议（非阻断）：参数的作用范围大于其名称和帮助文本
initTimeoutMs 在 acp-bridge/src/bridge.ts 中有 26 处使用，其中只有 1 处是 initialize 握手。其余是 newSession、sessionSource、sessionParent、审批模式、模型切换、workspace 状态轮询、transcript 以及另外约 20 个 ext-method 的超时。这是实测的，不只是读代码：
子进程延迟 session/new 14 s |
参数 | 结果 |
|---|---|---|
| 是 | （无） | HTTP 500 AcpSessionBridge newSession timed out after 10000ms @ 10 183 ms |
| 是 | --initialize-timeout-ms 30000 |
HTTP 200 @ 14 197 ms |
对于冷容器场景，这种连带效果其实是有益的 —— 冷启动的子进程在 newSession 上同样慢。但 --initialize-timeout-ms 300000 也意味着一个卡死的子进程可以占住 workspace 状态轮询长达五分钟，而帮助文本（ACP initialize handshake timeout (ms)）完全没有暗示这一点。建议把描述扩写为类似"ACP 子进程请求超时，包含 initialize 握手（毫秒）"。
7. 建议（非阻断）：文档未更新
所有同类 serve 超时参数都有文档，唯独这个参数在承载这些表格的四个文件中都没有出现：
docs/developers/daemon/17-configuration.mddocs/developers/daemon/20-quickstart-operations.mddocs/developers/daemon/02-serve-runtime.mddocs/users/qwen-serve.md
干净的部分
npm run typecheck—— 通过（退出码 0，全部 workspace）- 对全部 11 个改动文件跑
eslint—— 无问题 packages/channels/base—— 82/82 通过serve.test.ts+run-qwen-serve.test.ts（本 PR 新增的 4 个测试）—— 通过- CI 的
Serve A/B与web-shell E2E Smoke—— 通过
结论
建议修改后再合并 —— 与 @jifeng 相同的三项，在 94c51d5 上均仍未解决，另加两条非阻断建议：
- 阻断 —— 把
initialize-timeout-ms加入sampleArgvByOption，让 CI 转绿。 - 阻断 —— 为
initializeTimeoutMs增加2_147_483_647上界（建议复用assertTimerDelayInRange）并补上界回归测试。 - 阻断 —— rebase 或拆分，让
59150c5（fix(channels): exclude discrete ACP messages from replies #7223）离开本 diff；超时改动应当可以独立评审和独立回滚。 - 非阻断 —— 与同类参数一起补充文档。
- 非阻断 —— 调整帮助文本，说明它作用于 ACP 子进程请求整体，而不仅仅是
initialize。
底层改动方向明确、接线正确（包括 fast-path 的跟进）。上述 1–3 处理之后，我乐见其合并。
|
🤖 Addressed the latest review feedback (round 3/5). What changed, and what I pushed back on: Review feedback addressedCommit: Blocking items
Non-blocking items (addressed per early-round policy)
Verification
ConflictNo conflict ( 中文说明已处理的评审反馈提交： 阻断项
非阻断项（按早期评审轮次策略已处理）
验证结果
冲突无冲突（ Base-conflict check: no conflict with main. Re-review when you have a moment. After round 5 this bot stops and leaves the PR for a human. 🧠 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.
Reviewed. 1 Suggestion-level finding(s) could not be anchored to a changed line and were dropped; nothing further to act on here.
— qwen3.7-max via Qwen Code /review
|
🤖 Reviewed the latest feedback — no changes needed. Why, point by point: No action taken on PR #7246Review feedbackThe automated reviewer ( Failed CI check:
|
| Check | Result |
|---|---|
npm run build |
✅ pass |
npm run typecheck |
✅ pass |
npm run lint |
✅ pass |
| Prettier (changed files) | ✅ pass |
| Settings schema freshness | ✅ up-to-date |
| Serve fast-path bundle closure | ✅ pass |
serve.test.ts (10 tests) |
✅ pass |
fast-path.test.ts (all tests) |
✅ pass |
run-qwen-serve.test.ts (188 tests) |
✅ pass |
server.test.ts (762 tests) |
✅ pass |
acp-bridge package (858 tests) |
✅ pass |
The CI failure is caused by pre-existing test failures in packages/core (34 tests in src/config/storage.test.ts and src/core/logger.test.ts). These same tests fail identically on origin/main (verified by checking out origin/main and re-running them). This PR modifies zero files in packages/core; the failures are environment-related (filesystem path assumptions in the sandbox) and unrelated to the --initialize-timeout-ms change.
中文说明
未对 PR #7246 采取任何操作
评审反馈
自动评审机器人（qwen-code-ci-bot）留下了一条 COMMENTED 状态的评审，其中包含 1 条 Suggestion 级别的发现，但因无法锚定到已更改的代码行而被丢弃。没有行内评论或 Issue 级别的评论。评审中没有可操作的内容。
CI 检查失败：Test (ubuntu-latest Node 22.x)
在本地调查了该失败。本 PR 可能影响的所有检查在当前分支上均通过：
| 检查项 | 结果 |
|---|---|
npm run build |
✅ 通过 |
npm run typecheck |
✅ 通过 |
npm run lint |
✅ 通过 |
| Prettier（已更改文件） | ✅ 通过 |
| 设置 schema 是否为最新 | ✅ 已是最新 |
| Serve 快速路径 bundle 闭包检查 | ✅ 通过 |
serve.test.ts（10 个测试） |
✅ 通过 |
fast-path.test.ts（所有测试） |
✅ 通过 |
run-qwen-serve.test.ts（188 个测试） |
✅ 通过 |
server.test.ts（762 个测试） |
✅ 通过 |
acp-bridge 包（858 个测试） |
✅ 通过 |
CI 失败是由 packages/core 中预先存在的测试失败 导致的（src/config/storage.test.ts 和 src/core/logger.test.ts 中的 34 个测试）。这些相同的测试在 origin/main 上同样失败（已通过检出 origin/main 并重新运行验证）。本 PR 未修改 packages/core 中的任何文件；这些失败与沙箱环境中的文件系统路径假设有关，与 --initialize-timeout-ms 更改无关。
Base-conflict check: no conflict with main.
🧠 Handled by Qwen Code · model/模型 qwen3.8-max-preview
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Reviewed. Not reviewed: coverage — could not read the agents' transcripts (no subagent transcripts at /home/github-runner/actions-runner-7/_work/_temp/qwen-home/projects/-home-github-runner-actions-runner-7--work-qwen-code-qwen-code/subagents/0cfb13c1-4ada-44bc-9e04-933701daef30 (ENOENT: no such file or directory, scandir '/home/github-runner/actions-runner-7/_work/_temp/qwen-home/projects/-home-github-runner-actions-runner-7--work-qwen-code-qwen-code/subagents/0cfb13c1-4ada-44bc-9e04-933701daef30'). The harness writes one per agent; if there are none, either no agents ran or the harness could not write them.), so this run cannot show that any of the diff was read. Not reviewed: verification — could not check that Step 4 and Step 5 ran (no subagent transcripts at /home/github-runner/actions-runner-7/_work/_temp/qwen-home/projects/-home-github-runner-actions-runner-7--work-qwen-code-qwen-code/subagents/0cfb13c1-4ada-44bc-9e04-933701daef30 (ENOENT: no such file or directory, scandir '/home/github-runner/actions-runner-7/_work/_temp/qwen-home/projects/-home-github-runner-actions-runner-7--work-qwen-code-qwen-code/subagents/0cfb13c1-4ada-44bc-9e04-933701daef30'). The harness writes one per agent; if there are none, either no agents ran or the harness could not write them.).
— qwen3.7-max via Qwen Code /review
doudouOUC
left a comment
doudouOUC
left a comment
There was a problem hiding this comment.
Reviewed diff-only — the PR’s existing discussion could not be fetched, so this is not an approval and not a no-blockers claim. Suggestions are inline. Not reviewed: issue-fidelity — pr-context failed (context-unavailable). Not reviewed: Agent 0: Issue fidelity & root-cause ownership — its prompt was built, but no agent on record was launched with it.
— qwen3.7-max via Qwen Code /review
| if (opts.initializeTimeoutMs !== undefined) { | ||
| if ( | ||
| !Number.isFinite(opts.initializeTimeoutMs) || | ||
| !Number.isInteger(opts.initializeTimeoutMs) || | ||
| opts.initializeTimeoutMs <= 0 | ||
| ) { |
There was a problem hiding this comment.
[Suggestion] This inlined predicate (!isFinite || !isInteger || <= 0) is the exact logical negation of the existing isPositiveIntegerMs() helper at line 246 of this file. promptDeadlineMs (line 2323) and writerIdleTimeoutMs (line 2369) both call that helper. Inlining the same three checks creates maintenance divergence: if the helper is ever tightened or relaxed, this block silently drifts out of sync.
| if (opts.initializeTimeoutMs !== undefined) { | |
| if ( | |
| !Number.isFinite(opts.initializeTimeoutMs) || | |
| !Number.isInteger(opts.initializeTimeoutMs) || | |
| opts.initializeTimeoutMs <= 0 | |
| ) { | |
| if (opts.initializeTimeoutMs !== undefined) { | |
| if (!isPositiveIntegerMs(opts.initializeTimeoutMs)) { |
— qwen3.7-max via Qwen Code /review
|
🤖 Addressed the latest review feedback (round 4/5). What changed, and what I pushed back on: Review feedback addressedFeedback triage
Changes
Conflict notesNo conflicts ( Verification
中文说明已处理的评审反馈反馈分类
变更内容
冲突说明无冲突（ 验证结果
Base-conflict check: no conflict with main. Re-review when you have a moment. After round 5 this bot stops and leaves the PR for a human. 🧠 Handled by Qwen Code · model/模型 |
✅ Maintainer verification — built and tested locally (Linux)Verified this PR end-to-end on Linux against a real build ( What I checked
Evidence 1 — boot validation (real
|
| 项目 | 结果 |
|---|---|
工作区构建（tsc --noEmit）+ 打包 |
✅ 通过；参数出现在发布产物 dist/chunks/*（serve、fast-path、run-qwen-serve、server） |
对 5 个改动源文件跑 prettier --check |
✅ 干净 |
新增/改动单测（serve.test.ts、run-qwen-serve.test.ts、fast-path.test.ts） |
✅ 292 通过 / 0 失败；6 个新用例非空断言（能观测到抛出的 TypeError） |
| 通过真实 CLI 做启动期校验 | ✅ 0、-5、notanumber(→NaN)、2147483648(> 2³¹‑1) 均在启动时被拒；30000 与「不带参数」正常启动 |
初始化超时差分实测（真实守护进程 + 真实 qwen --acp 子进程） |
✅ 参数值原样传导到 ACP initialize 超时 |
证据 1 —— 启动期校验（真实 qwen serve）
每个非法值都在启动时快速失败，报错正是 runQwenServe 边界的那条消息；合法值（及缺省默认）正常监听。
证据 2 —— 参数确实控制着 ACP initialize 超时
这是最关键的一点：把值设得极小，会让启动期 preheat 的 initialize 握手超时，且报错消息里嵌入了参数的确切值（1 → "…after 1ms"，3 → "3ms"，5 → "5ms"），而 30000 则顺利完成 preheat。真实 qwen --acp 子进程在每次运行中都能正常启动（channel exited … SIGTERM）——唯一变化的就是配置的超时值。这证明 CLI 值确实到达了 bridge.ts 的 initTimeoutMs，后者用 withTimeout(…, initTimeoutMs, 'initialize') 包裹 connection.initialize(...)。
传导链（全覆盖）
--initialize-timeout-ms → serve.ts（yargs）→ runQwenServe({ initializeTimeoutMs }) → 边界处校验 → 全部 4 处 bridge 构造点都传入：
run-qwen-serve.ts:3358（主）、:3673（次级）、:4047（工作区运行时）server.ts:773（createServeApp内嵌/测试回退路径）
→ createAcpSessionBridge(opts) → initTimeoutMs = opts.initializeTimeoutMs ?? DEFAULT_INIT_TIMEOUT_MS (10000) → 作为 ACP 请求超时用在约 25 处（initialize、newSession、workspace-status、各 ext-method）。BridgeOptions.initializeTimeoutMs 本就存在，本 PR 只是把它暴露到 CLI，所以改动面确实很小。
非阻塞性提示（仅供参考，不影响合并）
- 描述里的测试数量少算了。 正文写「4 个新测试」，实际是 6 个 ——
serve.test.ts×2（解析 + 默认未设置）、run-qwen-serve.test.ts×3（非正 / 非有限 / > 2³¹‑1）、fast-path.test.ts×1（往返）。比宣称的覆盖更多，无需修改，仅作说明。 - 上限/整数校验只在 serve 边界，bridge 内部没有。
run-qwen-serve.ts正确地拒绝非整数 / > 2³¹‑1，但 bridge 自身的守卫（bridge.ts:1304）仍只检查<= 0。若有内嵌调用方直接createAcpSessionBridge({ initializeTimeoutMs: 3e9 })，会绕过上限检查、被 Node 静默压缩成 1 ms。这属于既有 bridge 行为、不在本 PR 范围（本 PR 关注的 CLI 路径已完全守护）；仅在你想做纵深防御跟进时提一句。
亮点：校验逻辑与同族的 permissionResponseTimeoutMs / channelIdleTimeoutMs 保持一致；不带参数时默认行为不变；文档（默认 10000、拒绝超上限）与我观测到的运行时行为一致。
Verified locally on Linux · real build + unit tests + live daemon/child E2E · not a substitute for CI.
|
@qwen-code /triage |
|
Triage re-run completed without a new review. The stage comments above were updated with the latest result. View workflow run. |
|
Qwen Code review timed out. Qwen review timed out after 300 seconds (of the 180-minute budget). For large PRs, retry with a longer timeout by commenting: |
|
🤖 Addressed the latest review feedback (round 5/5). What changed, and what I pushed back on: Autofix review response — PR #7246Addressed the new review feedback on top of head Feedback triage
Change made
if (opts.initializeTimeoutMs !== undefined) {
- if (
- !Number.isFinite(opts.initializeTimeoutMs) ||
- !Number.isInteger(opts.initializeTimeoutMs) ||
- opts.initializeTimeoutMs <= 0
- ) {
+ if (!isPositiveIntegerMs(opts.initializeTimeoutMs)) {
throw new TypeError(
`Invalid initializeTimeoutMs: ${opts.initializeTimeoutMs}. Must be a positive integer (milliseconds).`,
);This is behavior-preserving: Commit: Verification
中文说明Autofix 评审回应 — PR #7246在 head 反馈分类
所做改动
if (opts.initializeTimeoutMs !== undefined) {
- if (
- !Number.isFinite(opts.initializeTimeoutMs) ||
- !Number.isInteger(opts.initializeTimeoutMs) ||
- opts.initializeTimeoutMs <= 0
- ) {
+ if (!isPositiveIntegerMs(opts.initializeTimeoutMs)) {
throw new TypeError(
`Invalid initializeTimeoutMs: ${opts.initializeTimeoutMs}. Must be a positive integer (milliseconds).`,
);此改动保持行为不变： 提交： 验证
Base-conflict check: no conflict with main. Re-review when you have a moment. After round 5 this bot stops and leaves the PR for a human. 🧠 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.
No issues found. LGTM! ✅
— qwen3.7-max via Qwen Code /review
Local build + real-test verification — ✅ safe to mergeI verified this PR locally on Linux with real code paths (not just re-running the PR's own unit tests). Summary: the wiring is correct and load-bearing, all suites are green, the change is isolated and additive, and a runtime end-to-end proves the flag actually governs the ACP 1. Wiring is real, not a no-op
2. Runtime end-to-end (the decisive check)I drove the real
3. Unit suites (from source) + RED/GREEN discriminationAll touched suites green:
Notes (non-blocking)
Verdict: correct, well-scoped, additive, no regressions. LGTM. 👍 中文说明本地构建 + 真实测试验证 —— ✅ 可以合并我在本地 Linux 上用真实代码路径验证了这个 PR（不只是重跑 PR 自带的单测）。结论：接线正确且真正生效，所有测试套件通过，改动隔离且是增量式的，并且用一个运行时端到端测试证明了该参数确实控制 ACP 1. 接线是真实的，不是空操作
2. 运行时端到端（决定性验证）我驱动了真实的
3. 单元测试（源码运行）+ RED/GREEN 判别改动涉及的套件全绿： 备注（不阻塞合并）
结论： 正确、范围合理、增量式、无回归。LGTM。👍 🤖 Verified locally with Claude Code (claude-opus-4-8). |
… deleting a marker (QwenLM#7354) * feat(autofix): re-arm a stranded PR with @qwen-code /retry instead of deleting a marker Recovering a stranded managed PR meant running `gh api -X DELETE` against the bot's own autofix-eval marker comment. That needed raw API access and the comment id, erased the audit trail, and was undiscoverable unless you had read the workflow — it came up twice while triaging QwenLM#7246, QwenLM#7329 and QwenLM#7336. `@qwen-code /retry` now posts a single `<!-- autofix-rearm -->` marker, which does both halves of what the deletion did: - The scan's watermark ignores eval markers written BEFORE the newest re-arm, so the feedback those markers buried is read again. The watermark stays global otherwise — this is an explicit, maintainer-issued exception, which is exactly what the deletion was, only recorded instead of destructive. - The marker also opens a fresh counting window (it joins the engage ack in REARM_KEY), so the round counter resets and a terminal round stops skipping the PR. That also means the existing "a re-arm supersedes queued old-window jobs" guard covers /retry for free. The address job's live recheck mirrors both, so a run selected before a re-arm still discards itself instead of stamping an old-sequence marker. Authorization is the takeover command's, unchanged and reused rather than reinvented: exact body match, live permission lookup, in-repo-only author privilege. The route prefilter now admits the second command. The job verifies CI_DEV_BOT_PAT authenticates as the bot before commenting, because both scanners only count markers authored by it. The marker is registered as a control comment so the agent never sees the re-arm as feedback to address. Tests: the real extracted scan block is replayed over synthetic comment fixtures — stranded (watermark held, round 2), after /retry (watermark released, window reset, round 0), a marker written after the re-arm counting again, and a re-arm from a non-bot author correctly ignored. Both halves mutation-verified. * test(autofix): add behavioral test for address-side re-arm stale check (QwenLM#7354) * fix(autofix): generalize remaining command-ignored messages and assert all filter sites (QwenLM#7354) * test(autofix): add behavioral test for the retry-command re-arm marker job (QwenLM#7354) --------- Co-authored-by: wenshao <wenshao@example.com> Co-authored-by: qwen-code-dev-bot <qwen-code-dev-bot@users.noreply.github.com>
…wenLM#7355) * feat(autofix): render the managed fleet into the scan's run summary Seeing whether the loop was healthy meant reconstructing it by hand: list the bot's PRs, fetch each one's comments, regex the autofix-eval markers for round and watermark, then cross-check gh pr checks and the fork/takeover state. That is how today's triage of QwenLM#7246, QwenLM#7259, QwenLM#7329, QwenLM#7333 and QwenLM#7336 was done, and it is why a stalled PR stayed invisible until somebody went looking for it. The scan already computes every one of those facts while deciding what to process — it just wrote them to a job log nobody reads. Each per-PR terminal decision now also records a row, and the step renders one markdown table into the run summary: | PR | State | Detail | | QwenLM#7329 | SELECTED | 1 review + 5 inline new (round 0/5) | | QwenLM#7333 | idle | nothing new since 2026-07-20T13:54:18Z | | QwenLM#7262 | waiting | active checks in flight | | QwenLM#7208 | round-capped | round 100/100 - needs a human or @qwen-code /retry | States cover every branch that ends a PR's inspection: busy, skipped, unknown, waiting, round-capped, idle and SELECTED — so a PR cannot drop out of the table by returning early, which is exactly the invisibility this fixes. No new API calls (the data is already in hand), no writes outside the run summary, and the helper is defined at the top of the step so it stays clear of the BUSY_PRS/INSPECTED proximity guard that keeps the free busy-skip from consuming the inspection budget. Tests: the real helper and render block are replayed over fixtures (table structure, one row per state, and an empty fleet still rendering a table), plus each decision branch is pinned to its fleet_row. Mutation-verified: dropping one branch's row turns it red. * fix(autofix): use temp file for fleet test replay; cover fork-head skip (QwenLM#7355) * test(autofix): assert each skipped fleet_row call site individually (QwenLM#7355) * fix(autofix): record fleet rows for both budget-break paths (QwenLM#7355) The candidate-inspection budget break incremented INSPECTED but never called fleet_row, so the PR that tripped the budget was silently absent from the fleet table. The target-budget break left all remaining candidates invisible with no truncation signal. Add a per-PR deferred row before the inspection-budget break and a summary deferred row before the target-budget break so the fleet table stays complete in both cases. * fix(autofix): harden fleet summary render and clean up temp file (QwenLM#7355) Address review feedback: - Escape '|' in detail values to prevent broken table columns - Render budget summary row (PR '-') as em dash instead of '#-' - Add trap for FLEET_FILE cleanup on early exit paths - Document deferred summary row semantics in test comment * fix(autofix): use summary row for candidate-inspection budget break (QwenLM#7355) --------- Co-authored-by: wenshao <wenshao@example.com> Co-authored-by: qwen-code-ci-bot <qwen-code-ci-bot@users.noreply.github.com> Co-authored-by: qwen-code-dev-bot <qwen-code-dev-bot@users.noreply.github.com> Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
|
Released in v0.20.1. |
What this PR does
Adds an
--initialize-timeout-msCLI flag toqwen servethat wires through toBridgeOptions.initializeTimeoutMs, allowing operators to override the ACPinitializehandshake timeout (default 10 000 ms). The flag accepts a positive integer in milliseconds; unset preserves the current 10 s default. Validation rejects non-finite and non-positive values at therunQwenServeboundary, mirroring the existingpermissionResponseTimeoutMsandchannelIdleTimeoutMspatterns.Why it's needed
In containerized deployments the ACP child process can take longer than 10 s to complete the
initializehandshake (e.g. ~12 s during cold container startup). The first user query then fails with an init timeout while subsequent queries succeed because the child is already warm. Operators currently have no way to raise the timeout without patching the source. The desktop app already supportsQWEN_ACP_INITIALIZE_TIMEOUT_MS, but the CLI/serve path does not read it.Reviewer Test Plan
How to verify
Unit tests cover flag parsing and validation:
All 4 new tests pass (2 parsing + 2 validation).
Manual: start
qwen serve --initialize-timeout-ms 30000and confirm the ACP child gets a 30 s initialize window (observable viaDEBUG=1bridge logs).Evidence (Before & After)
N/A — no user-visible TUI change; behavior is exercised by unit tests.
Tested on
Environment (optional)
Local Node workspace,
npx vitest run.Risk & Scope
Linked Issues
Fixes #7244
中文说明
这个 PR 做了什么
为
qwen serve新增--initialize-timeout-msCLI 参数，将其传递给BridgeOptions.initializeTimeoutMs，允许运维人员覆盖 ACPinitialize握手超时（默认 10 000 ms）。参数接受正整数（毫秒）；未设置时保持当前 10 s 默认值。验证逻辑在runQwenServe边界拒绝非有限和非正值，与现有permissionResponseTimeoutMs和channelIdleTimeoutMs模式一致。为什么需要
在容器化部署中，ACP 子进程可能需要超过 10 s 才能完成
initialize握手（例如冷容器启动时约 12 s）。首次用户查询会因初始化超时而失败，而后续查询因子进程已就绪而正常。运维人员目前无法在不修改源码的情况下提高超时。桌面应用已支持QWEN_ACP_INITIALIZE_TIMEOUT_MS环境变量，但 CLI/serve 路径不读取它。复核测试计划
单元测试覆盖参数解析和验证：
4 个新测试全部通过（2 个解析 + 2 个验证）。
手动验证：启动
qwen serve --initialize-timeout-ms 30000，确认 ACP 子进程获得 30 s 初始化窗口（可通过DEBUG=1bridge 日志观察）。风险与范围