🏆 ยอดนิยม: QwenLM/qwen code/pull/

qwen-code-dev-bot · 2026-10-09T14:16:09Z

What this PR does

Makes the two container-mode tests in the Managed Runtime container-entry suite stop binding the hard-coded container port 43190 for real. A new test-local helper spies on the HTTP server's listen, keeps the requested (43190, '0.0.0.0') arguments observable for assertions, but performs the actual bind on an ephemeral loopback port (0, '127.0.0.1') — the same pattern the sibling attestation-worker suite already uses for its own container-mode test. The explicit-port test still asserts the worker was asked to listen on (43190, '0.0.0.0'), and now derives the expected ready URL from the actually bound address instead of a hard-coded port. No production code changes.

Why it's needed

A main-branch CI run failed on exactly these two tests (issue #13775, run 37925143593 at 8c127de524a6). Both tests bind fixed port 43190 on 0.0.0.0; the Test (ubuntu-latest, Node 22.x) job can run on the shared self-hosted ecs-qwen fleet where several jobs share one host, so any neighbor holding 43190 fails both tests with EADDRINUSE while everything else passes. Locally holding the port with a throwaway process reproduces the identical failure signature (2 failed / 11 passed, listen EADDRINUSE: address already in use 0.0.0.0:43190); with this change the suite passes whether or not 43190 is occupied.

Reviewer Test Plan

How to verify

Confirm the flake mechanism and its removal: in one shell, hold the port with node -e "require('node:net').createServer().listen(43190, '0.0.0.0', () => setInterval(() => {}, 1000))"; in another, run cd packages/cli && npx vitest run src/serve/managed-runtime-container.test.ts. Before this change the two container-mode tests fail with EADDRINUSE; after it, all 13 tests pass. Also run the file normally (port free) — all 13 tests pass — and npx vitest run src/serve/managed-runtime-container.test.ts src/serve/managed-runtime-attestation-worker.test.ts for the pair of container-mode suites (42 passed). The retained behavioral witness: mutating the source bind port from 43190 to anything else makes opens the explicit container port with authenticated attestation fail at the toHaveBeenCalledWith(43190, '0.0.0.0') assertion.

Evidence (Before & After)

N/A — test-only change, no user-visible behavior.

Tested on

OS	Status
🍏 macOS	⚠️
🪟 Windows	⚠️
🐧 Linux	✅

Environment (optional)

N/A — unit tests only (npx vitest run in packages/cli).

Risk & Scope

Main risk or tradeoff: the container-mode tests no longer exercise a real bind to the fixed port; that is deliberate (it is what made them flaky on shared CI hosts) and the explicit-port request remains asserted via the listen spy, matching the sibling suite's established pattern.
Not validated / out of scope: the real 43190 bind in production container startup is unchanged and untested here; other suites' use of fixed ports was not audited.
Breaking changes / migration notes: none.

Linked Issues

Fixes #13775

中文说明

这个 PR 做了什么

让 Managed Runtime 容器入口测试套件中的两个容器模式测试不再真实绑定硬编码的容器端口 43190。新增的测试内辅助函数 spy HTTP 服务器的 listen,保留可断言的请求参数 (43190, '0.0.0.0'),但真实绑定改为临时回环端口 (0, '127.0.0.1')——与兄弟 attestation-worker 测试套件为其容器模式测试采用的模式一致。显式端口测试仍然断言 worker 被要求监听 (43190, '0.0.0.0'),并改为从实际绑定的地址推导期望的 ready URL,而不再硬编码端口。不改动任何生产代码。

为什么需要

主分支的一次 CI 运行恰好在这两个测试上失败(issue #13775,运行 37925143593,提交 8c127de524a6)。两个测试都在 0.0.0.0 上绑定固定端口 43190;Test (ubuntu-latest, Node 22.x) 作业可能运行在共享的自托管 ecs-qwen 机群上,多个作业共享同一台主机,因此任何占用 43190 的邻居都会让这两个测试以 EADDRINUSE 失败,而其余测试全部通过。本地用一个临时进程占用该端口即可复现完全相同的失败特征(2 失败 / 11 通过,listen EADDRINUSE: address already in use 0.0.0.0:43190);应用本改动后,无论 43190 是否被占用,套件都能通过。

评审验证计划

如何验证

确认抖动机制及其消除:在一个终端中用 node -e "require('node:net').createServer().listen(43190, '0.0.0.0', () => setInterval(() => {}, 1000))" 占用端口;在另一个终端中运行 cd packages/cli && npx vitest run src/serve/managed-runtime-container.test.ts。改动前,两个容器模式测试以 EADDRINUSE 失败;改动后,13 个测试全部通过。同时在端口空闲时正常运行该文件——13 个测试全部通过——并用 npx vitest run src/serve/managed-runtime-container.test.ts src/serve/managed-runtime-attestation-worker.test.ts 运行两个容器模式套件(42 个通过)。保留的行为见证:将源码中的绑定端口从 43190 改成任何其他值,会使 opens the explicit container port with authenticated attestation 在 toHaveBeenCalledWith(43190, '0.0.0.0') 断言处失败。

前后对比证据

N/A —— 仅测试改动,无用户可见行为。

测试平台

OS	Status
🍏 macOS	⚠️
🪟 Windows	⚠️
🐧 Linux	✅

环境(可选)

N/A —— 仅单元测试(在 packages/cli 中 npx vitest run)。

风险与范围

主要风险或权衡:容器模式测试不再真实绑定固定端口;这是有意为之(正是在共享 CI 主机上造成抖动的原因),且显式端口请求仍通过 listen spy 断言,与兄弟套件的既有模式一致。
未验证 / 超出范围:生产环境容器启动时真实的 43190 绑定保持不变,不在本 PR 测试范围内;未审计其他套件对固定端口的使用。
破坏性变更 / 迁移说明:无。

关联 Issue

Fixes #13775

Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>

qwen-code-dev-bot · 2026-10-09T14:16:11Z

Autofix E2E Report — Issue #13775

Summary

Main CI (Test (ubuntu-latest, Node 22.x), run 37925143593, commit 8c127de524a6) failed on exactly two tests in packages/cli/src/serve/managed-runtime-container.test.ts:

Managed Runtime container entry > wires the gate in the actual boot3 startup while preserving boot2 route ownership
Managed Runtime container entry > opens the explicit container port with authenticated attestation

These are the only two tests in the file — and, after this fix, in the package — that bind the hard-coded container port 43190 on 0.0.0.0 for real. The job runs on the shared self-hosted ecs-qwen fleet where several jobs share one host (see the maxWorkers/RUNNER_NAME notes in packages/cli/vitest.config.ts and the CI workflow's per-fork bounding), so a neighbor job or leftover process holding 43190 makes both tests fail with EADDRINUSE while everything else passes.

Root cause

startManagedRuntimeAttestationWorker(..., containerMode = true) always binds the fixed port 43190 on 0.0.0.0 (managed-runtime-attestation-worker.ts). The sibling suite managed-runtime-attestation-worker.test.ts had already solved this for its own container-mode test: it mocks Server.prototype.listen so the worker is still asked for (43190, '0.0.0.0') while the real socket binds an ephemeral loopback port (0, '127.0.0.1'). managed-runtime-container.test.ts never adopted that pattern and bound 43190 for real — fine in isolation, flaky on a shared CI host.

Reproduction (before the fix)

With a throwaway holder process occupying the port (net.createServer().listen(43190, '0.0.0.0')), running npx vitest run src/serve/managed-runtime-container.test.ts in packages/cli reproduced the CI signature exactly:

× Managed Runtime container entry > wires the gate in the actual boot3 startup while preserving boot2 route ownership
  → listen EADDRINUSE: address already in use 0.0.0.0:43190
× Managed Runtime container entry > opens the explicit container port with authenticated attestation
  → listen EADDRINUSE: address already in use 0.0.0.0:43190
Tests  2 failed | 11 passed (13)

Exactly the two tests from the issue failed; every other test in the file passed.

Fix

Test-only change in managed-runtime-container.test.ts, following the pattern the sibling suite established:

Added a small mockEphemeralListen() helper that spies on Server.prototype.listen, keeps the requested (43190, '0.0.0.0') arguments observable, but performs the real bind on (0, '127.0.0.1') — an ephemeral loopback port that cannot collide with anything off-process.
wires the gate in the actual boot3 startup… uses the helper before starting the container worker; all of its traffic already goes through worker.ready.url, which both createManagedContextReady (boot v2/v3) and the v1 ready record derive from the actually bound port, so nothing else in the test changed.
opens the explicit container port with authenticated attestation now asserts listen was called with (43190, '0.0.0.0') — preserving the "explicit container port" witness — and asserts worker.ready.url against the real bound address instead of a hard-coded 43190. The authenticated-attestation flow (401 without a token, 200 with it, no-store, token never echoed) is unchanged.

No production code was modified.

Verification

node -e port-holder + cd packages/cli && npx vitest run src/serve/managed-runtime-container.test.ts (before fix) — reproduced: 2 failed / 11 passed with EADDRINUSE 0.0.0.0:43190, matching the CI signature.
Mutation probe: temporarily changed the source bind port 43190 → 43191 in managed-runtime-attestation-worker.ts and reran the file — opens the explicit container port with authenticated attestation failed at expect(listen).toHaveBeenCalledWith(43190, '0.0.0.0'), proving the assertion still witnesses the explicit-port behavior. Source restored and confirmed via grep.
cd packages/cli && npx vitest run src/serve/managed-runtime-container.test.ts (after fix, port free) — 13 passed / 13.
Port-holder + same command (after fix, port 43190 occupied) — 13 passed / 13: the original failure condition no longer affects the suite.
cd packages/cli && npx vitest run src/serve/managed-runtime-container.test.ts src/serve/managed-runtime-attestation-worker.test.ts — 42 passed / 42 across both container-mode suites.
npm run build — passed.
npm run typecheck — passed.
npm run lint — passed (also re-checked by the pre-commit hook: prettier + eslint on the staged file, clean).

Environment note: the exact CI failure was host-specific (shared ecs-qwen runner), so it cannot be replayed against the real CI environment locally; the held-port probe above is the faithful surrogate and reproduces the identical failing signature. The workflow's independent CI remains the final gate.

中文说明

Autofix E2E 报告 — Issue #13775

摘要

主分支 CI(Test (ubuntu-latest, Node 22.x),运行 37925143593,提交 8c127de524a6)恰好在 packages/cli/src/serve/managed-runtime-container.test.ts 的两个测试上失败:

Managed Runtime container entry > wires the gate in the actual boot3 startup while preserving boot2 route ownership
Managed Runtime container entry > opens the explicit container port with authenticated attestation

这两个是该文件中——以及本次修复后整个包中——仅有的真实绑定硬编码容器端口 43190(0.0.0.0)的测试。该 CI 作业运行在共享的自托管 ecs-qwen 机群上,多个作业共享同一台主机(见 packages/cli/vitest.config.ts 中关于 maxWorkers/RUNNER_NAME 的注释以及 CI 工作流中的 fork 数量限制),因此邻居作业或残留进程占用 43190 时,这两个测试会以 EADDRINUSE 失败,而其余测试全部通过。

根因

startManagedRuntimeAttestationWorker(..., containerMode = true) 总是绑定固定端口 43190(0.0.0.0,见 managed-runtime-attestation-worker.ts)。同目录的兄弟测试套件 managed-runtime-attestation-worker.test.ts 早已为它自己的容器模式测试解决了这个问题:它 mock Server.prototype.listen,使 worker 仍然以 (43190, '0.0.0.0') 被调用,而真实 socket 绑定到临时回环端口 (0, '127.0.0.1')。managed-runtime-container.test.ts 从未采用这个模式,而是真实绑定 43190——单独运行时没问题,在共享 CI 主机上则会抖动失败。

复现(修复前)

用一个临时进程占用该端口(net.createServer().listen(43190, '0.0.0.0'))后,在 packages/cli 中运行 npx vitest run src/serve/managed-runtime-container.test.ts,精确复现了 CI 的失败特征:

× Managed Runtime container entry > wires the gate in the actual boot3 startup while preserving boot2 route ownership
  → listen EADDRINUSE: address already in use 0.0.0.0:43190
× Managed Runtime container entry > opens the explicit container port with authenticated attestation
  → listen EADDRINUSE: address already in use 0.0.0.0:43190
Tests  2 failed | 11 passed (13)

恰好是 issue 中列出的两个测试失败,文件中其余测试全部通过。

修复

仅修改 managed-runtime-container.test.ts 测试文件,沿用兄弟套件已建立的模式:

新增小型 mockEphemeralListen() 辅助函数:spy Server.prototype.listen,保留可断言的请求参数 (43190, '0.0.0.0'),但真实绑定改为 (0, '127.0.0.1')——一个不会与进程外任何东西冲突的临时回环端口。
wires the gate in the actual boot3 startup… 在启动容器 worker 前调用该辅助函数;它的所有请求本来就经由 worker.ready.url,而 createManagedContextReady(boot v2/v3)和 v1 ready 记录都从实际绑定的端口生成 URL,因此该测试其余部分无需改动。
opens the explicit container port with authenticated attestation 现在断言 listen 以 (43190, '0.0.0.0') 被调用——保留"显式容器端口"这一行为见证——并基于真实绑定地址断言 worker.ready.url,而不再硬编码 43190。认证证明流程(无 token 返回 401,带 token 返回 200,no-store 头,token 不回显)保持不变。

未修改任何生产代码。

验证

node -e 占位进程 + cd packages/cli && npx vitest run src/serve/managed-runtime-container.test.ts(修复前)——复现成功:2 失败 / 11 通过,报 EADDRINUSE 0.0.0.0:43190,与 CI 特征一致。
变异探针:临时将 managed-runtime-attestation-worker.ts 中的绑定端口 43190 改为 43191 并重跑该文件——opens the explicit container port with authenticated attestation 在 expect(listen).toHaveBeenCalledWith(43190, '0.0.0.0') 处失败,证明该断言仍在见证显式端口行为。源码已恢复并用 grep 确认。
cd packages/cli && npx vitest run src/serve/managed-runtime-container.test.ts(修复后,端口空闲)——13 通过 / 13。
占位进程 + 同一命令(修复后,43190 被占用)——13 通过 / 13:原始失败条件不再影响该套件。
cd packages/cli && npx vitest run src/serve/managed-runtime-container.test.ts src/serve/managed-runtime-attestation-worker.test.ts——两个容器模式套件共 42 通过 / 42。
npm run build——通过。
npm run typecheck——通过。
npm run lint——通过(pre-commit 钩子也对暂存文件运行了 prettier + eslint,无修改)。

环境说明:确切的 CI 失败是主机相关的(共享 ecs-qwen runner),无法在本地对真实 CI 环境重放;上述占位端口探针是忠实的替代验证,复现了完全相同的失败特征。工作流独立的 CI 仍是最终验证关卡。

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.25.0

qwen-code-review-bot · 2026-10-09T14:17:15Z

✅ Qwen Triage finished — view run. See the stage comments in this thread for the result.

✅ Qwen Triage 已完成 —— 查看运行。结果见本线程中的各阶段评论。

qwen-code-review-bot · 2026-10-09T14:24:40Z

Thanks for the PR. This is a re-run, and the head has moved since my last pass (6991d18b → 39d9dd57), so everything below is a fresh read of the current commit rather than a restatement of the old one.

Template looks good ✓ — all nine headings present, and the Risk & Scope section states the coverage trade plainly instead of burying it.

Problem: observed, not theoretical. Issue #13775 is a real main CI failure — run 37925143593 at 8c127de524a6, job Test (ubuntu-latest, Node 22.x), step Run tests and generate reports — and it names exactly the two tests this PR touches. I also read the production bind myself rather than taking the description's word for it: managed-runtime-attestation-worker.ts:292 really does server.listen(containerMode ? 43190 : 0, containerMode ? '0.0.0.0' : '127.0.0.1'). So on the shared self-hosted fleet a neighbour holding 43190 fails both container-mode tests with EADDRINUSE while everything else passes. Mechanism confirmed end to end.

Direction: aligned. A hard-coded port in a suite that runs on hosts with neighbours is a flake generator by construction, and CI reliability is squarely in scope. CHANGELOG: no direct reference, but the area is relevant — this is test-suite hygiene with no user-facing surface.

Size: not applicable. No core paths — both changed files are packages/cli/src/serve/*.test.ts, so production logic lines are 0 and all 32 changed lines are test lines. No generated or schema files.

Approach: minimal, and it reuses an existing precedent rather than inventing a mechanism. I checked the completeness question that actually matters here — whether some other test still binds 43190 for real, which would leave the flake half-fixed. Grepping the tree for 43190 finds it only in these two test files, in production, and in the Java pod-spec/URI declarations (which construct container specs and endpoints; they don't bind a socket). All six startManagedRuntimeAttestationWorker call sites in the container suite are accounted for: the two that reach a real bind are exactly the two that got the mock, and the other four either default to non-container mode (listen(0, '127.0.0.1'), already ephemeral) or reject before the listener opens. The fix is complete for this port.

One scope question, offered as a question rather than an objection: commit 410f707f also edits the sibling attestation-worker suite, which was not itself flaky, and that widens its real bind from loopback to the requested wildcard address. Applying the same shape to both copies is what stops the two from drifting apart — and it was my own R1-1 suggestion last round that prompted the change — so I think those 2 lines are well spent. Naming it so the choice is visible rather than incidental.

Risk: no elevated risk signals. Stage 1e matched nothing; both paths are excluded as .test.ts before the high-risk pattern check even runs.

Moving on to code review. 🔍

中文说明

感谢贡献。这是一次 re-run，head 自我上次审查后已经移动（6991d18b → 39d9dd57），因此下面所有内容都是对当前提交的重新阅读，而不是对旧结论的复述。

模板完整 ✓ —— 九个标题齐全，Risk & Scope 部分把覆盖面上的取舍讲得很清楚，没有回避。

问题：已观测到，不是理论性的。 issue #13775 是一次真实的 main CI 失败 —— 提交 8c127de524a6 上的运行 37925143593，作业 Test (ubuntu-latest, Node 22.x)，步骤 Run tests and generate reports —— 它点名的正是本 PR 改动的那两个测试。我也自己读了生产代码的绑定逻辑，而不是采信描述：managed-runtime-attestation-worker.ts:292 确实是 server.listen(containerMode ? 43190 : 0, containerMode ? '0.0.0.0' : '127.0.0.1')。所以在共享的自托管机群上，任何占用 43190 的邻居都会让这两个容器模式测试以 EADDRINUSE 失败，而其余测试全部通过。机制已完整核实。

方向：对齐。在一个与邻居共享主机的测试套件里硬编码端口，本身就是抖动来源；CI 稳定性完全属于本项目范围。CHANGELOG：无直接引用，但该领域相关 —— 这是测试套件层面的卫生问题，没有用户可见面。

规模：不适用。未触及核心路径 —— 两个改动文件都是 packages/cli/src/serve/*.test.ts，因此生产代码行数为 0，全部 32 行改动均为测试行。无生成文件或 schema 文件。

方案：改动很小，且复用了既有先例而没有另造机制。我核查了这里真正关键的完整性问题 —— 是否还有其他测试仍在真实绑定 43190，那样抖动就只修了一半。在整个代码树中搜索 43190，只出现在这两个测试文件、生产代码，以及 Java 的 pod spec / URI 声明中（后者构造容器规格与端点，并不绑定套接字）。容器测试套件中全部六处 startManagedRuntimeAttestationWorker 调用点都已核对：真正会执行绑定的两处，正是加了 mock 的那两处；其余四处要么默认为非容器模式（listen(0, '127.0.0.1')，本来就是临时端口），要么在监听器打开之前就已 reject。就这个端口而言，修复是完整的。

一个范围上的疑问，是提问而不是反对：提交 410f707f 还改动了兄弟 attestation-worker 套件，而它本身并不抖动，这一改动把它的真实绑定从回环地址放宽到了请求的通配地址。让两份副本保持同形，正是防止二者日后漂移的办法 —— 而且促成这次改动的正是我上一轮的 R1-1 建议 —— 所以我认为这 2 行花得值。点出来是为了让这个选择是显式的，而不是顺手带过的。

风险：无升级风险信号。Stage 1e 未命中任何模式；两个路径在高风险模式检查运行之前就已被 .test.ts 规则排除。

进入代码审查 🔍

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 39d9dd574a4101101fdb2f451ab0d18fdbf7a45b · re-run with @qwen-code /triage}

qwen-code-review-bot · 2026-10-09T14:28:57Z

Code review

My independent proposal last round was the same shape this PR took — spy on listen, keep the requested arguments assertable, bind an ephemeral port for real — so the interesting question on this re-run is narrower: did commit 410f707f restore the host witness that my R1-1 said was lost, without breaking the port witness or the flake fix? For that delta my own baseline was "override only the port, forward the caller's remaining arguments", which is literally what landed.

Both witnesses now hold, and I checked each against production rather than against the description:

Port witness. expect(listen).toHaveBeenCalledWith(43190, '0.0.0.0') reads the recorded call arguments, not the socket. Production passes exactly those two arguments at managed-runtime-attestation-worker.ts:292-295 — no callback, it waits on the 'listening' event instead. Change the port in production and the recorded arguments change, so the assertion fails. The ephemeral real bind does not weaken it.
Host witness. Because the mock forwards args.slice(1), a container-mode worker really binds 0.0.0.0:<ephemeral>, while production builds url: http://127.0.0.1:${address.port} (line 313) and the test expects that literal. Had production switched to deriving the host from the bound address, ready.url would come back as http://0.0.0.0:<port> and the assertion would go red. This is precisely the witness R1-1 flagged as self-referential at the previous head; it is back, and it is back for the right reason — the port is substituted, the host is not.

Two smaller things I verified because a prototype-level mock is easy to get subtly wrong:

Argument shape. Reflect.apply(nativeListen, this, [0, ...args.slice(1)]) keeps any trailing arguments, so a future listen(port, host, cb) still receives its callback. The previous form ([0, '127.0.0.1']) replaced the whole argument list and would have silently dropped one. Strictly better, and the substituted port stays 0, so the EADDRINUSE collision this PR removes is not reintroduced through the back door.
Mock lifecycle. The helper's return value is discarded at the first call site, which is only safe because afterEach(() => vi.restoreAllMocks()) at line 63 covers it; the sibling restores in its own finally. No spy leaks into the rest of the suite.

Non-blocking nit, not worth a round trip on a test-only change: listen.mock.results[0]?.value?.address() as AddressInfo uses a cast that discards the ?. chain's undefined case, so if a worker ever failed to listen the test would die on a TypeError instead of a readable assertion. It still goes red, just less helpfully.

The residual the PR discloses is real and I accept it: no test now proves a genuine bind to 43190 succeeds inside a container. That proof was the flake, so removing it is the fix rather than a side effect. If we ever want it back it belongs in an isolated lane with the port guaranteed free — not in a shared unit suite running on a host with neighbours.

On conventions: the helper's comment is the kind AGENTS.md actually asks for — it explains a non-obvious why (the port is deliberately not really bound, and forcing loopback would make the URL assertion self-referential), which is exactly what stops a future reader "fixing" it back into a flake. Type-only import via import type, no production delta, no drive-by refactors in either file.

Test evidence

This is a CI-path re-run (GITHUB_EVENT_NAME=issue_comment), so per the skill's rules I executed nothing: no build, no test run, no checkout of the PR branch, and no PR-derived code. Every check below is the PR's own CI, read through the API for the reviewed commit 39d9dd57 — 25 check-runs, 22 success, 3 skipped, 0 failure, 0 pending.

The load-bearing one is Test (ubuntu-latest, Node 22.x) — the exact job and step that failed on main in issue #13775 — and it is success here. Lint & Static (ubuntu-latest, Node 22.x) is green too, which covers typecheck and lint for the new AddressInfo import and the rest-parameter mock signature. The two SDK Java jobs that flaked at the previous head in Initialize containers (before checkout, so no repository code ran) are both success on this commit, consistent with the author's transient-infra diagnosis. Test (macos-latest, …), Test (windows-latest, …) and Integration Tests (CLI, No Sandbox) are skipped, which is this repo's normal matrix pruning for a change of this shape, not a gap the PR caused.

The author's local vitest counts and mutation probes are their own claim and I did not lean on them for the verdict — I verified both witnesses statically by reading production and the assertions, so nothing in my conclusion rests on a result I could not check myself.

Check	Conclusion
Classify PR	success
Desktop Shell (ubuntu-22.04)	success
Desktop Shell (windows-2022)	success
Flyway migration version uniqueness	success
Hosted process fault gates / MySQL 8.4 / Java 21	success
Integration Tests (CLI, No Sandbox)	skipped
Integration Tests (no-AK, No Sandbox)	success
Lint & Static (ubuntu-latest, Node 22.x)	success
OpenTUI no-flicker gate	success
Real daemon E2E / Java 11	success
Remind on force-push	success
Runtime Broker and Managed Agent MariaDB / Java 21	success
Serve A/B (ubuntu-latest, Node 22.x)	success
TUI parity snapshots (ink vs opentui)	success
Test (macos-latest, Node 22.x)	skipped
Test (ubuntu-latest, Node 22.x)	success
Test (windows-latest, Node 22.x)	skipped
assign	success
label	success
macos-latest / Java 21	success
ubuntu-latest / Java 11	success
ubuntu-latest / Java 17	success
ubuntu-latest / Java 21	success
web-shell E2E Smoke (ubuntu-latest, Node 22.x)	success
windows-latest / Java 21	success

Real-scenario testing: N/A — nothing user-visible (test-only, zero production lines), and on the CI path the live-behaviour signal comes from the PR's own checks above rather than from a locally driven session. There is also no behavioural claim left for a sandboxed lane to settle: the port witness follows from how a spy records call arguments, the host witness follows from the mock forwarding the requested host while production hard-codes loopback in the URL, and the suite's green state comes from the job that previously flaked.

中文说明

代码审查

我上一轮的独立方案与本 PR 采用的形式相同 —— spy listen、保留可断言的请求参数、真实绑定改到临时端口 —— 所以这次 re-run 上真正有意思的问题更窄：提交 410f707f 是否恢复了我 R1-1 指出已丢失的主机见证，同时没有破坏端口见证、也没有把抖动带回来。针对这一段增量，我自己的基线方案就是"只覆盖端口，转发调用方其余参数"，而落地的正是这个。

两个见证现在都成立，且我都是对着生产代码核对的，而不是对着 PR 描述：

端口见证。 expect(listen).toHaveBeenCalledWith(43190, '0.0.0.0') 读的是记录下来的调用参数，不是套接字。生产代码在 managed-runtime-attestation-worker.ts:292-295 恰好只传这两个参数 —— 没有回调，它改为等待 'listening' 事件。改掉生产代码里的端口，记录到的参数就会变，断言随之失败。真实的临时端口绑定并不会削弱它。
主机见证。 由于 mock 转发了 args.slice(1)，容器模式的 worker 会真实绑定 0.0.0.0:<临时端口>，而生产代码构造的是 url: http://127.0.0.1:${address.port}（第 313 行），测试断言的正是这个字面量。如果生产代码改成从实际绑定地址推导主机，ready.url 就会变成 http://0.0.0.0:<port>，断言立刻变红。这正是 R1-1 指出在上一个 head 上已退化为自证的那个见证；它回来了，而且回来的理由是对的 —— 被替换的是端口，不是主机。

另外两点我特意核实了，因为 prototype 级别的 mock 很容易出微妙的错：

参数形状。 Reflect.apply(nativeListen, this, [0, ...args.slice(1)]) 保留了后续参数，因此将来若出现 listen(port, host, cb)，回调仍能收到。此前的形式（[0, '127.0.0.1']）会整体替换参数列表，将悄悄丢掉回调。新写法严格更优；且被替换的端口仍为 0，所以本 PR 消除的 EADDRINUSE 冲突不会从后门被重新引入。
mock 生命周期。 第一处调用丢弃了 helper 的返回值，这之所以安全，是因为第 63 行的 afterEach(() => vi.restoreAllMocks()) 覆盖了它；兄弟文件则在自己的 finally 中恢复。没有 spy 泄漏到套件其余部分。

一个不阻塞的小点，在纯测试改动上不值得多走一轮：listen.mock.results[0]?.value?.address() as AddressInfo 用类型断言丢掉了 ?. 链的 undefined 分支，所以万一某个 worker 没能进入监听，测试会以 TypeError 崩掉，而不是给出可读的断言失败。它仍然会变红，只是提示没那么友好。

PR 自己披露的残留确实存在，我也接受：现在没有测试能证明容器内真实绑定 43190 会成功。而那个证明本身就是抖动来源，所以移除它是本次修复的目的，不是副作用。如果将来想补回来，应该放在能保证端口空闲的隔离通道里，而不是放在与邻居共享主机的单元测试套件中。

规范方面：helper 上方那段注释正是 AGENTS.md 所要求的那一类 —— 它解释了不显然的为什么（端口是故意不真实绑定的，而强制回环会使 URL 断言退化为自证），这恰恰是阻止后来者把它"修"回抖动状态所需要的信息。类型导入使用 import type，无生产代码改动，两个文件都没有夹带顺手重构。

测试证据

这是一次 CI 路径的 re-run（GITHUB_EVENT_NAME=issue_comment），因此按 skill 规则我没有执行任何东西：没有构建、没有跑测试、没有检出 PR 分支，也没有运行任何来自 PR 的代码。下面每一项都是本 PR 自己的 CI，通过 API 读取被审提交 39d9dd57 的结果 —— 共 25 个 check-run，22 成功、3 跳过、0 失败、0 待运行。

最关键的是 Test (ubuntu-latest, Node 22.x) —— 正是 issue #13775 中在 main 上失败的那个作业与步骤 —— 在本次提交上为 success。Lint & Static (ubuntu-latest, Node 22.x) 同样为绿，覆盖了新增 AddressInfo 导入与 rest 参数 mock 签名的 typecheck 与 lint。上一个 head 上在 Initialize containers 阶段抖动的两个 SDK Java 作业（发生在 checkout 之前，因此没有运行任何仓库代码），在本提交上均为 success，与作者的瞬时基础设施故障判断一致。Test (macos-latest, …)、Test (windows-latest, …) 与 Integration Tests (CLI, No Sandbox) 为 skipped，这是本仓库针对此类改动的正常矩阵裁剪，不是本 PR 造成的缺口。

作者本地的 vitest 数量与变异探针属于其自述，我的结论没有依赖它们 —— 我通过阅读生产代码与断言，静态核实了两个见证，因此结论中没有任何部分建立在我无法亲自核查的结果之上。

（上方表格为 CI 检查项与结论的机器可读区域，此处不再重复。）

真实场景测试：N/A —— 没有用户可见改动（纯测试，生产代码 0 行）；且在 CI 路径上，实时行为信号来自上面的 CI 检查，而不是本地驱动的会话。也没有留给沙箱通道去验证的行为性断言：端口见证源于 spy 记录调用参数的机制，主机见证源于 mock 转发请求主机、而生产代码在 URL 中硬编码回环这一组合，套件的绿色状态则来自此前抖动的那个作业本身。

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 39d9dd574a4101101fdb2f451ab0d18fdbf7a45b · re-run with @qwen-code /triage}

qwen-code-review-bot · 2026-10-09T14:31:01Z

Confidence: 4/5 — clean across every stage and CI is fully green on the job that flaked; the single point keeping it from 5 is the disclosed coverage trade, which is inherent to the fix rather than a defect in it.

Stepping back over the whole picture: the problem is a real main failure with a run ID and a named job, the mechanism is confirmed by reading the production bind rather than the PR description, and the fix removes the fixed port from exactly the two call sites that reach a real socket while leaving the four that don't. My independent proposal for this delta — override the port only, forward the caller's remaining arguments — is what shipped, so there is no simpler path I think it missed.

The failure mode I went looking for is the one that matters on an autofix PR pointed at a flaky test: making CI green by weakening the assertion. That did not happen, and this head is stronger than the one I reviewed last round. At 6991d18b the helper replaced the whole argument list, which quietly turned the rewritten ready.url expectation into a self-referential check. 410f707f fixed that by forwarding the requested host, so a container worker really binds 0.0.0.0:<ephemeral> while production still publishes a loopback URL — and the assertion now pins both halves: what production asks for (toHaveBeenCalledWith(43190, '0.0.0.0'), read off the recorded arguments) and what it publishes (http://127.0.0.1:<bound port>, which only holds because the real bind is on the wildcard address). I confirmed both against managed-runtime-attestation-worker.ts lines 292-295 and 313 rather than taking the round-2 summary's word for it.

Nothing was deleted to get to green, and the diff carries no drive-by refactors. The one scope question — the sibling suite was edited too, and was not itself flaky — I've already answered in my favour: two copies of the same mock that behave differently is how the next person re-introduces this bug, and 2 lines to prevent that is cheap. It also followed from my own R1-1, so holding it against the author would be inconsistent.

Would I curse or thank the author in six months? Thank them. The comment above the helper says why the port is deliberately not really bound and why forcing loopback would break the URL witness — that is precisely the note a future reader needs to avoid "fixing" this back into a flake. The residual is honest and stated in the PR: no test now proves a genuine 43190 bind succeeds in a container, and that proof was the flake. If we want it back, it belongs in an isolated lane with the port guaranteed free, not in the shared unit suite. Carrying that is the right trade.

The non-blocking nit (the as AddressInfo cast dropping the clean-failure path) is not worth a round trip on a test-only change with zero production lines.

Verification posture, stated plainly so nobody has to guess what this run did and did not do: this is a CI-path re-run, so I executed nothing — no build, no test run, no PR checkout. The evidence is the PR's own 25 check-runs at 39d9dd57 (22 success, 3 skipped, 0 failure, 0 pending), with Test (ubuntu-latest, Node 22.x) — the job that failed on main — green. Both assertion witnesses I verified statically, by reading production and the assertions, so my verdict does not rest on the author's self-reported mutation probes. The three skipped matrix legs are this repo's normal pruning for a change of this shape.

Approval guardrail: not triggered. This is a same-repo branch (isCrossRepository: false) and the title is test(cli):, not a refactor, so nothing caps the score or blocks an approval. Stage 0 raised no escalation either — no core paths, 0 production logic lines.

Unlike last round, there is no CI left to wait for: zero workflow runs with event == "pull_request" are in flight on this commit, so the approval is given here rather than deferred, and it is pinned to the reviewed commit through the reviews API. The stale deferral marker my previous Stage 3 comment carried for 6991d18b is removed by this update — that commit is no longer the head, and branch protection had already dismissed the approval attached to it.

中文说明

信心：4/5 —— 各阶段均无问题，且在此前抖动的那个作业上 CI 已全绿；没到 5 分的唯一一点，是本 PR 主动披露的覆盖取舍，而那是本次修复固有的代价，不是改动本身的缺陷。

退一步看整体：问题是一次有运行编号、有作业名的真实 main 失败；机制是通过阅读生产代码的绑定逻辑核实的，而不是采信 PR 描述；修复恰好从真正会打开套接字的那两处调用点移除了固定端口，而其余四处未被触及。针对这一段增量，我的独立方案 —— 只覆盖端口、转发调用方其余参数 —— 正是落地的方案，所以不存在我认为它漏掉的更简路径。

我特意去找的失效模式，是 autofix PR 对着 flaky 测试时最该警惕的那一种：靠削弱断言把 CI 变绿。这里没有发生，而且当前 head 比我上一轮审查的那个更强。在 6991d18b 上，helper 整体替换了参数列表，悄悄把改写后的 ready.url 断言变成了自证。410f707f 通过转发请求的主机修复了这一点，因此容器 worker 真实绑定 0.0.0.0:<临时端口>，而生产代码仍发布回环 URL —— 断言现在同时钉住了两半：生产代码请求什么（toHaveBeenCalledWith(43190, '0.0.0.0')，读的是记录下来的参数），以及它发布什么（http://127.0.0.1:<实际绑定端口>，而这只有在真实绑定于通配地址时才成立）。这两点我都是对着 managed-runtime-attestation-worker.ts 第 292-295 行与第 313 行核实的，没有采信第 2 轮总结的说法。

没有为了变绿而删东西，diff 也没有夹带顺手重构。唯一的范围疑问 —— 兄弟套件也被改了，而它本身并不抖动 —— 我已经给出了对自己有说服力的答案：同一个 mock 的两份副本若行为不同，正是下一个人重新引入这个 bug 的途径；用 2 行防止这种事，成本很低。而且这次改动源自我自己的 R1-1，若以此苛责作者并不一致。

六个月后我会感谢作者还是咒骂作者？感谢。helper 上方那段注释说明了端口为什么是故意不真实绑定的、以及强制回环为什么会破坏 URL 见证 —— 这正是后来者所需要的信息，能防止他们把它"修"回抖动状态。残留是诚实的，PR 里也写明了：现在没有测试能证明容器内真实绑定 43190 会成功，而那个证明本身就是抖动来源。若想补回来，应放在能保证端口空闲的隔离通道中，而不是共享的单元测试套件里。承担这个代价是正确的取舍。

那个不阻塞的小点（as AddressInfo 断言丢掉了干净失败路径）在一个生产代码为 0 行的纯测试改动上不值得多走一轮。

验证姿态说明清楚，免得有人需要猜这次运行做了什么、没做什么：这是 CI 路径的 re-run，所以我没有执行任何东西 —— 没有构建、没有跑测试、没有检出 PR。证据是本 PR 自己在 39d9dd57 上的 25 个 check-run（22 成功、3 跳过、0 失败、0 待运行），其中 Test (ubuntu-latest, Node 22.x) —— 正是在 main 上失败的那个作业 —— 为绿。两个断言见证都是我静态核实的，方式是阅读生产代码与断言，因此我的结论不依赖作者自述的变异探针。三条被跳过的矩阵分支是本仓库针对此类改动的正常裁剪。

批准护栏：未触发。这是同仓库分支（isCrossRepository: false），标题是 test(cli): 而非 refactor，因此没有任何规则压低分数或阻止批准。Stage 0 也未提出上报 —— 无核心路径，生产代码 0 行。

与上一轮不同，这次没有需要等待的 CI：该提交上没有任何 event == "pull_request" 的 workflow run 在飞行中，所以批准在此直接给出，而非延后，并通过 reviews API 与被审提交绑定。我上一条 Stage 3 评论中为 6991d18b 携带的延后标记已由本次更新移除 —— 该提交已不是 head，且分支保护此前已经驳回了附在其上的批准。

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 39d9dd574a4101101fdb2f451ab0d18fdbf7a45b · re-run with @qwen-code /triage}

qwen-code-review-bot · 2026-10-09T14:36:41Z

🩺 serve daemon A/B

Built the PR base vs this PR head 39d9dd5, drove a fixed endpoint set against each, and diffed the JSON responses. Only fields that changed are shown.

`health-deep-with-session`

field	PR base (before)	this PR (after)
`activeWorkStaleMs`	`6`	`5`

— Qwen Code · serve A/B

yiliang114

Reviewed at head 6991d18 — LGTM.

The fix has the right shape for the #13775 flake: the spy keeps the requested (43190, '0.0.0.0') bind observable for the assertion while the real socket moves to an ephemeral loopback port, so a neighbor process holding 43190 on a shared CI host can no longer fail these tests.

Verified against the head source, not just the diff:

The production worker calls server.listen(port, host) with no callback and derives readiness from server.once('listening', …) plus server.address(), so the mock forwarding only [0, '127.0.0.1'] cannot stall startup, and worker.ready.url reflects the actually bound address — matching the new derived-URL assertion.
Both container-mode tests issue their follow-up requests against worker.ready.url; no hard-coded 43190 remains anywhere in the file outside the call-argument assertion.
The existing afterEach runs vi.restoreAllMocks(), so the prototype spy cannot leak into sibling tests.
Same pattern the attestation-worker suite already established, so it stays consistent across the two files.

CI on this head shows no failures so far (a few lanes still running).

qwen-code-review-bot

Approving at head 6991d18. Test-only, one file, +19/−6; I confirmed no production source is touched, then checked the four things that decide whether a flake fix like this is real or just quiets the symptom.

The mechanism is the one in the logs, and the fix removes it rather than tolerating it. Both container-mode tests bound a hard-coded 43190 on 0.0.0.0, so any neighbor holding that port on the shared ecs-qwen host fails them with EADDRINUSE while everything else passes — matching the #13775 signature. mockEphemeralListen() (:85-91) keeps the requested arguments observable and moves the real bind to (0, '127.0.0.1'), so the suite is now indifferent to whether 43190 is occupied. Nothing was skipped, gated on port availability, or wrapped in a retry — which is what would have made this a silenced flake instead of a fixed one.

The sibling-pattern claim checks out. managed-runtime-attestation-worker.test.ts:625-639 already does exactly this: same const nativeListen = Server.prototype.listen, same Reflect.apply(nativeListen, this, [0, '127.0.0.1']), same expect(listen).toHaveBeenCalledWith(43190, '0.0.0.0'). This PR converges on an existing in-repo pattern rather than inventing one.

The spy does not leak. The first call site (:147) discards the return value, which is safe because this file has afterEach(async () => { vi.restoreAllMocks(); ... }) at :63-64. Worth noting the two suites restore differently — the sibling calls listen.mockRestore() inline at :660 — but both are correct, and restoreAllMocks covers the discarded handle.

The behavioral witness survives, with one trade the PR discloses. The old assertion inspected the actually bound socket (address() matching {address: '0.0.0.0', port: 43190}); the new one asserts the requested arguments. That is inherent to not binding the port, and the port-number witness is preserved — mutating the production bind port still fails toHaveBeenCalledWith(43190, '0.0.0.0'). Two things I specifically checked rather than assumed:

expect(worker.ready.url).toBe(\http://127.0.0.1:${address.port}\`)` (:329) still pins the host rewrite, because 127.0.0.1 is literal in the expectation while only the port is derived. Had both sides been derived, the "ready URL reports loopback, not the wildcard bind address" contract would have become unfalsifiable.
The tests still do real HTTP against the real socket — fetch(worker.ready.url + route, ...) at :181 and the attest POST at :330 — so this is not a mock asserting its own return value. Only the port number is ephemeral.

The residual trade: neither container-mode test now witnesses a wildcard 0.0.0.0 bind actually succeeding. That coverage still exists in the sibling suite, which probes wildcard listeners separately at :279-288.

Not verified: I ran nothing locally — this box cannot hold the workspace (~1.2 GB free), so the EADDRINUSE-while-held reproduction and the 13/13 and 42/42 pass counts in the description are the author's, unreproduced by me. Test (ubuntu-latest, Node 22.x) and Lint & Static are green at this head; the Java lanes and web-shell E2E Smoke were still running, and cannot be affected by a CLI unit-test file.

Disclosure: this PR was authored by qwen-code-dev-bot and my review comes from qwen-code-review-bot — both accounts in the same automation family, so this approval is not an independent human check. Recording that as a fact rather than treating it as a blocker: the diff is test-only and I verified it line by line, but a maintainer's eyes remain the only independent review this PR will have had.

qwen-code-review-bot

Reviewed — no blockers. Suggestions are inline.

Test Plan (not a blocker): src/serve/managed-runtime-container.test.ts — no such file or directory; src/serve/managed-runtime-attestation-worker.test.ts — no such file or directory; 13 tests pass — this review observed 40057, 609 passed; 42 passed — this review observed 40057, 609 passed.

中文说明

已审查——无阻断问题。建议见行内评论。

Test Plan（非阻断）：src/serve/managed-runtime-container.test.ts — no such file or directory; src/serve/managed-runtime-attestation-worker.test.ts — no such file or directory; 13 tests pass — this review observed 40057, 609 passed; 42 passed — this review observed 40057, 609 passed。

— qwen3.8-max via Qwen Code /review (v0.25.0)

qwen-code-dev-bot · 2026-10-09T20:32:59Z

🕐 Review received — an automatic review of the current head is still running, so this round is held until it lands (a push now would cancel it and discard its work, #8888). Your feedback stays queued for the next eligible round.

中文说明

🕐 已收到评审 —— 当前 head 上仍有一轮自动 review 在运行，本轮暂缓（现在推送会取消该 review 并丢弃其工作，#8888）。反馈保持排队，等待下一次可运行的轮次处理。

qwen-code-dev-bot · 2026-10-09T20:55:42Z

✅ AutoFix round 2 finished — view run. See this round's report below.

中文说明

✅ AutoFix 第 2 轮已完成 —— 查看运行。本轮报告见下方。

…13775) Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>

qwen-code-dev-bot · 2026-10-09T21:32:59Z

🤖 Addressed the latest review feedback (round 1/10). What changed, and what I pushed back on: · 已处理最新评审反馈（第 1/10 轮）。改动内容与我反驳保留之处如下：

Round summary

Addressed the single inline suggestion from the round-1 review. One commit: 410f707fdc test(cli): forward the requested bind host in ephemeral listen mocks (#13775).

Feedback dispositions

[rc:4234307856] R1-1 (Suggestion) — implemented. The mockEphemeralListen helper introduced by this PR replaced the caller's entire argument list with [0, '127.0.0.1'], so the container-mode test bound loopback instead of the requested wildcard address — silently stripping the rewritten ready.url assertion of its host witness (a worker publishing http://0.0.0.0:<port> would have stayed green). Both listen mocks now override only the port and forward the caller's own arguments ([0, ...args.slice(1)]), so the container worker really binds 0.0.0.0:<ephemeral> while the first test's non-container worker keeps 127.0.0.1. The fix was applied to both copies (managed-runtime-container.test.ts and the pattern's source in managed-runtime-attestation-worker.test.ts) so they cannot drift, and the helper comment now states why only the port is substituted. The substituted port stays 0, so the fixed-port EADDRINUSE collision this PR removed is not reintroduced. No production code changed.

Reproduction and mutation probes

Pre-fix probe (claim reproduction): mutated managed-runtime-attestation-worker.ts to derive the ready-URL host from the bound address (url: `http://${address.address}:${address.port}` ); managed-runtime-container.test.ts stayed green — 13/13 passed — confirming the mutant survives at the pre-round head and the witness was indeed lost.
Post-fix probe: with the same mutation re-applied, opens the explicit container port with authenticated attestation failed with expected 'http://0.0.0.0:39589' to be 'http://127.0.0.1:39589' — the witness is restored. The other 12 container tests and all 29 attestation-worker tests still passed under the mutation.
Production was then restored byte-identically (exact-string replacement, count-asserted both ways) and both suites re-run green (42/42).

Other feedback

The review-level "Test Plan" observations and the serve A/B activeWorkStaleMs 6→5 delta are informational timing noise, not findings; no action taken.
No failed checks were listed for this round.

Verification

npm run build — passed (exit 0). Required COREPACK_HOME=/tmp/corepack-cache because the sandbox denies corepack's default cache directory under $HOME (EACCES); with that override the full workspace build completed.
npm run typecheck — passed (exit 0).
npm run lint — passed (exit 0).
npx vitest run src/serve/managed-runtime-container.test.ts src/serve/managed-runtime-attestation-worker.test.ts (from packages/cli) — 2 files, 42 tests passed (13 + 29).
Mutation probes (described above): pre-fix mutant green → post-fix mutant red → production restored green.
Pre-commit hook (prettier + eslint --fix --max-warnings 0) ran on the staged files and produced no modifications.

中文说明

本轮总结

处理了第 1 轮评审中唯一的一条行内建议。产生一个提交：410f707fdc test(cli): forward the requested bind host in ephemeral listen mocks (#13775)。

反馈处置

[rc:4234307856] R1-1（建议）— 已实现。 本 PR 引入的 mockEphemeralListen 辅助函数此前用 [0, '127.0.0.1'] 整体替换调用方的参数列表，导致容器模式测试实际绑定回环地址而非请求的通配地址——这悄悄使改写后的 ready.url 断言失去了主机见证（即使 worker 发布 http://0.0.0.0:<port> 测试也仍为绿色）。现在两处 listen mock 都只覆盖端口并转发调用方自己的参数（[0, ...args.slice(1)]），因此容器 worker 真实绑定 0.0.0.0:<临时端口>，而第一个测试中的非容器 worker 仍保持 127.0.0.1。该修复同时应用于两份副本（managed-runtime-container.test.ts 以及该模式的来源 managed-runtime-attestation-worker.test.ts），防止两处继续漂移；辅助函数的注释也已更新，说明为什么只替换端口。替换后的端口保持为 0，不会重新引入本 PR 所消除的固定端口 EADDRINUSE 冲突。未改动任何生产代码。

复现与变异探针

修复前探针（复现评审断言）： 将 managed-runtime-attestation-worker.ts 变异为从实际绑定地址推导 ready-URL 主机（url: `http://${address.address}:${address.port}` ）；managed-runtime-container.test.ts 保持全绿——13/13 通过——证实该变异体在本轮前的 head 上确实存活，主机见证确已丢失。
修复后探针： 重新施加同一变异后，opens the explicit container port with authenticated attestation 失败，报 expected 'http://0.0.0.0:39589' to be 'http://127.0.0.1:39589'——见证已恢复。在变异存在的情况下，其余 12 个容器测试和全部 29 个 attestation-worker 测试仍然通过。
随后将生产代码逐字节还原（双向均为精确字符串替换并断言替换次数），两套测试重新运行全绿（42/42）。

其他反馈

评审级的 "Test Plan" 观察记录以及 serve A/B 中 activeWorkStaleMs 6→5 的差值属于信息性的时序噪声，并非发现；未采取行动。
本轮没有列出失败的检查。

验证

npm run build — 通过（退出码 0）。由于沙箱拒绝 corepack 在 $HOME 下创建默认缓存目录（EACCES），需要设置 COREPACK_HOME=/tmp/corepack-cache；使用该覆盖后整个工作区构建完成。
npm run typecheck — 通过（退出码 0）。
npm run lint — 通过（退出码 0）。
npx vitest run src/serve/managed-runtime-container.test.ts src/serve/managed-runtime-attestation-worker.test.ts（在 packages/cli 下运行）— 2 个文件，42 个测试通过（13 + 29）。
变异探针（如上所述）：修复前变异体为绿 → 修复后变异体变红 → 还原生产代码后恢复为绿。
pre-commit 钩子（prettier + eslint --fix --max-warnings 0）已在暂存文件上运行，未产生任何额外修改。

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/模型 kimi-k3 · CLI 0.25.0

qwen-code-dev-bot · 2026-10-09T23:03:27Z

🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下：

No action this round — both failed checks are CI infrastructure flakes, not code defects

Feedback triaged

Failed check: Runtime Broker and Managed Agent MariaDB / Java 21 (SDK Java workflow)
Failed check: Hosted process fault gates / MySQL 8.4 / Java 21 (SDK Java workflow)
No reviews, inline comments, or issue-level comments were pending.

Diagnosis (from evidence, not guesswork)

Both jobs failed in the Initialize containers step — before Checkout ever ran, so zero lines of repository code (from this PR or otherwise) executed in either job. Step-level data from the GitHub Jobs API for run 37994110766 (head SHA 410f707fdc):

Job	Failing step	Step duration	Checkout and all later steps
`Runtime Broker and Managed Agent MariaDB / Java 21` (job `114035593410`)	`Initialize containers` → FAILURE	21:33:00 → 21:33:42 (~42 s)	skipped
`Hosted process fault gates / MySQL 8.4 / Java 21` (job `114035593507`)	`Initialize containers` → FAILURE	21:33:00 → 21:33:45 (~45 s)	skipped

Corroborating evidence:

These jobs normally run for many minutes (their timeouts are 15 and 140 minutes); both died in under 50 seconds while pulling/starting the mariadb:10.11.18 / mysql:8.4.6 service containers.
They are the only two jobs in the SDK Java workflow that declare services: containers. Every sibling job in the same run on the same SHA succeeded: ubuntu/macos/windows × Java 11/17/21, Flyway migration version uniqueness, and Real daemon E2E / Java 11.
The six most recent SDK Java runs on main (latest 2026-10-09T16:18Z, SHA 5b1c701400) are all green, so the pinned images and the workflow definition are healthy — this is a transient runner/container-runtime failure, not a persistent breakage.
This PR's diff touches only two TypeScript test files (packages/cli/src/serve/managed-runtime-attestation-worker.test.ts, packages/cli/src/serve/managed-runtime-container.test.ts, +24/−8). Nothing in it can influence a Docker image pull on a GitHub-hosted runner, and the repository had not even been checked out when the failure occurred.

Why no code change

The failing surface is GitHub-hosted runner container infrastructure. The remedy for a transient container-init failure is re-running the failed jobs — a network write only the workflow or a maintainer can trigger.
Any durable hardening (e.g., image or workflow changes) would live in .github/workflows/sdk-java.yml, which is CI machinery outside this PR's footprint; the autofix loop is not permitted to modify it and must escalate such changes to a maintainer instead.
The PR's own test surface is green locally (see Verification), and the workflow's independent CI remains the final gate — a re-run of the two failed jobs should clear them.

Verification

git diff origin/main...HEAD — reviewed in full: 2 test files, +24/−8, test-only changes.
GitHub Jobs API for jobs 114035593410 and 114035593507 — both failed at Initialize containers; Checkout and every subsequent step skipped (evidence quoted above).
GitHub workflow-runs API for sdk-java.yml on main — 6/6 recent runs SUCCESS.
npm run build — passed (after setting COREPACK_HOME=/tmp/corepack-cache because the sandbox's default corepack cache path is read-only; the first attempt failed with EACCES: permission denied, mkdir '.../.cache/node/corepack/v1', which is an environment limitation, not a build defect).
npx vitest run src/serve/managed-runtime-attestation-worker.test.ts src/serve/managed-runtime-container.test.ts (packages/cli) — 42/42 tests passed.

No files were changed and no commit was made this round.

中文说明

本轮无需改动——两个失败的检查均为 CI 基础设施偶发故障,而非代码缺陷

已分类的反馈

失败的检查: Runtime Broker and Managed Agent MariaDB / Java 21(SDK Java 工作流)
失败的检查: Hosted process fault gates / MySQL 8.4 / Java 21(SDK Java 工作流)
没有待处理的 review、行内评论或 issue 级评论。

诊断(基于证据,而非猜测)

两个任务都失败在 Initialize containers 步骤——Checkout 尚未执行,因此这两个任务中没有运行任何仓库代码(无论是本 PR 的还是其他的)。来自 GitHub Jobs API 的运行 37994110766(head SHA 410f707fdc)的步骤级数据:

任务	失败步骤	步骤耗时	Checkout 及后续所有步骤
`Runtime Broker and Managed Agent MariaDB / Java 21`(任务 `114035593410`)	`Initialize containers` → 失败	21:33:00 → 21:33:42(约 42 秒)	跳过
`Hosted process fault gates / MySQL 8.4 / Java 21`(任务 `114035593507`)	`Initialize containers` → 失败	21:33:00 → 21:33:45(约 45 秒)	跳过

佐证:

这些任务正常运行需要数分钟(超时时间分别为 15 分钟和 140 分钟);两者都在拉取/启动 mariadb:10.11.18 / mysql:8.4.6 服务容器时于 50 秒内失败。
它们是 SDK Java 工作流中仅有的两个声明了 services: 容器的任务。同一运行、同一 SHA 上的所有其他任务全部成功:ubuntu/macos/windows × Java 11/17/21、Flyway migration version uniqueness 和 Real daemon E2E / Java 11。
main 分支上最近六次 SDK Java 运行(最近一次为 2026-10-09T16:18Z,SHA 5b1c701400)全部通过,说明固定的镜像和工作流定义是健康的——这是一次运行器/容器运行时的瞬时故障,而非持续性损坏。
本 PR 的 diff 只改动了两个 TypeScript 测试文件(packages/cli/src/serve/managed-runtime-attestation-worker.test.ts、packages/cli/src/serve/managed-runtime-container.test.ts,+24/−8)。其中没有任何内容能影响 GitHub 托管运行器上的 Docker 镜像拉取,而且故障发生时仓库甚至尚未被检出。

为什么不做代码改动

故障面在 GitHub 托管运行器的容器基础设施。对瞬时容器初始化故障的补救措施是重新运行失败的任务——这是只有工作流或维护者才能触发的网络写操作。
任何持久化的加固(例如镜像或工作流变更)都将落在 .github/workflows/sdk-java.yml,这属于本 PR 范围之外的 CI 基础设施;autofix 流程不允许修改它,此类变更必须上报给维护者。
本 PR 自身的测试面在本地是通过的(见下方验证),工作流的独立 CI 仍是最终门禁——重新运行这两个失败的任务应当即可恢复。

验证

git diff origin/main...HEAD —— 已完整审查:2 个测试文件,+24/−8,纯测试改动。
GitHub Jobs API 查询任务 114035593410 和 114035593507 —— 两者均失败于 Initialize containers;Checkout 及后续所有步骤均被跳过(证据如上)。
GitHub workflow-runs API 查询 main 分支的 sdk-java.yml —— 最近 6 次运行全部成功。
npm run build —— 通过(在设置 COREPACK_HOME=/tmp/corepack-cache 之后,因为沙箱默认的 corepack 缓存路径是只读的;首次尝试失败于 EACCES: permission denied, mkdir '.../.cache/node/corepack/v1',这是环境限制,不是构建缺陷)。
npx vitest run src/serve/managed-runtime-attestation-worker.test.ts src/serve/managed-runtime-container.test.ts(packages/cli)—— 42/42 个测试全部通过。

本轮未改动任何文件,也未创建提交。

Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。

🩸 Regression charged to round 1: that round pushed onto a head whose checks were all green and left them red. It no longer counts as progress for the consecutive-failure brake. · 已将回归记在第 1 轮：该轮在检查全绿的 head 上推送后检查转红，因此不再计入连续失败熔断的有进展判定。

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.25.0

qwen-code-dev-bot · 2026-10-10T00:26:18Z

🔀 Base updated: red check(s) [Runtime Broker and Managed Agent MariaDB / Java 21, Hosted process fault gates / MySQL 8.4 / Java 21] pass on current main — merged current main via update-branch; CI will re-run.

中文说明

🔀 已更新 base：红色检查 [Runtime Broker and Managed Agent MariaDB / Java 21, Hosted process fault gates / MySQL 8.4 / Java 21] 在当前 main 上通过 —— 已通过 update-branch 合入当前 main，CI 将重新运行。

wenshao · 2026-10-10T01:33:14Z

@qwen-code /triage

qwen-code-review-bot · 2026-10-10T01:36:19Z

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: 110 passed · 0 failed · 110 total

Flakiness gate: ✅ 2 changed test file(s) x 5 identical rounds, no divergence

中文 — 判定：✅ 通过 · 可合入（agent 判定）

沙箱验证在隔离、无凭证的容器中执行了该 PR 的代码（与 base 构建 A/B 对照、无 mock harness 断言、定向门禁）。仅作为评审证据，不构成评审、批准或 CI 检查。

脚本断言：110 通过 · 0 失败 · 110 总计

抖动门：✅ 2 changed test file(s) x 5 identical rounds, no divergence

Verification report

Verdict: merge-ready — 110 scripted assertions executed, 110 passed, 0 failed.
Verified head 39d9dd574a4101101fdb2f451ab0d18fdbf7a45b (git rev-parse HEAD^2), base c0c697c8a3d7d0460d37c497b76d52968c9216f7 (HEAD^1), merge commit under test 6537f1e1e036637398807baf5d7d144e5a6b8c19.

中文摘要

结论：merge-ready —— 本轮共执行 110 条脚本化断言，全部通过，0 条失败。

A/B 结论（中心主张成立、且是 load-bearing 的）：在 CI 容器中用一个无关进程占用 0.0.0.0:43190，对 base（HEAD^1 的独立 worktree）与 head 跑同一套件。base 复现 issue #13775：managed-runtime-container.test.ts 11/13 通过、2 个失败，失败信息正是 listen EADDRINUSE: address already in use 0.0.0.0:43190，且失败的恰好是两个容器模式用例；head 在端口被占用时 13/13 全绿，端口空闲时也 13/13。兄弟套件 managed-runtime-attestation-worker.test.ts 在两侧均 29/29。详见下文 A/B cell matrix 与 01-ab-port-collision-base-vs-head.png。

Findings：无阻塞项。两条 Suggestion 级观察（断言未按调用次序限定；commit 2 的 host 透传在兄弟套件中无测试可观测收益，并把该套件容器模式绑定的网卡从 127.0.0.1 放宽到 0.0.0.0）。均已实测界定，不影响合并。

变异矩阵：11 个变异体全部与预测一致（含 1 个正对照）。关键结果——生产端把 43190 改成 43191（M1）或把 '0.0.0.0' 改成 '127.0.0.1'（M2）都会让 opens the explicit container port… 在 toHaveBeenCalledWith(43190, '0.0.0.0') 处变红，PR 声称的行为见证成立；删掉任一 mockEphemeralListen()（M6/M7）在端口被占用时立刻以 EADDRINUSE 变红，证明两个 hunk 都是 load-bearing。组合变异 M10 是本轮最有价值的一条：单独回退 commit 2 的 host 透传（M3/M4）存活，但把 host 透传与"生产端改用 address.address 拼 ready.url"一起改时，M9 的击杀消失（42/42 全绿）——这实测证明了测试文件里那句注释的理由（强制 loopback 会让 ready.url 的 host 断言变成自证）是正确的。详见 Mutation matrix 与 02-mutation-matrix-kills-and-survivors.png。

未覆盖范围：packages/cli 全量单测（1234 个测试文件）未跑，只跑了受影响目录 src/serve（310 文件 / 13602 通过 / 0 失败）；depth-2 检出下 3 个提交只有 1 个可达，无法逐提交归因；无 GitHub token，无法核对本 PR 自身 CI 究竟跑了什么；macOS / Windows 未测；容器内真实绑定 43190 的生产路径未测（PR 已声明超范围）；sdk-java 侧同样引用 43190，但 QWEN_VERIFY_JAVA 未设置、容器内无 JDK，未执行。"仓库内没有别的测试真绑 43190" 这一条是静态普查结论，不是在占用端口下跑全量套件得到的；普查覆盖仓库源码中全部 224 处 .listen(<数字字面量>)，除 scripts/tests/managed-agent-dev.test.js:335 固定绑定 5174（在 packages/cli 之外，本轮未进一步审计）外全部使用 0（临时端口）。

Scope

The diff is test-only — 2 files, +24/−8, no production code:

file	change
`packages/cli/src/serve/managed-runtime-container.test.ts`	new test-local `mockEphemeralListen()` helper; used by the two container-mode tests; the explicit-port test now asserts `toHaveBeenCalledWith(43190, '0.0.0.0')` and derives the expected `ready.url` from the actually-bound port
`packages/cli/src/serve/managed-runtime-attestation-worker.test.ts`	its pre-existing ephemeral-listen mock widened from forcing `'127.0.0.1'` to forwarding the requested host

Central claim: the two container-mode tests stop binding hard-coded 0.0.0.0:43190 for real, so the suite passes whether or not a neighbour holds that port — while still pinning that production requests (43190, '0.0.0.0').

Secondary claims: (1) the retained behavioural witness — mutating the production bind port still reddens the explicit-port test at toHaveBeenCalledWith(43190, '0.0.0.0'); (2) the host forwarding in the new mock is what keeps the ready.url host assertion from becoming self-referential (the new code comment's stated rationale).

Because the PR is test-only, the method is a mutation A/B across test files plus a port-collision A/B against a real base control, not a behaviour A/B against production.

A/B cell matrix — the central claim is load-bearing

Control: git worktree add tmp/base-tree HEAD^1 (c0c697c8), with the root and per-package node_modules plus every packages/*/dist hardlinked in via cp -al (0.8 s), and npm run generate run inside the base tree so it carries its own git-commit.ts (c0c697c8, not head's 6537f1e1). The PR touches no manifest or lockfile, so reusing the installed tree is a clean control.

Internal-link confound checked, not assumed — from inside the base worktree every @qwen-code/* resolves into the base tree:

qwen-code-core -> /__w/qwen-code/qwen-code/tmp/base-tree/packages/core
qwen-code      -> /__w/qwen-code/qwen-code/tmp/base-tree/packages/cli
acp-bridge     -> /__w/qwen-code/qwen-code/tmp/base-tree/packages/acp-bridge
web-templates  -> /__w/qwen-code/qwen-code/tmp/base-tree/packages/web-templates

Comparator proven with a positive control: diff -r --brief over packages/cli/src/serve reports only the two changed test files, and after a one-token edit to managed-runtime-attestation-worker.ts (43190 → 43191) the same comparator additionally reports that file. So "production byte-identical" is a measurement, not an absence of output.

Port holder: an in-process Node net server bound to 0.0.0.0:43190 — the same mechanism as the node -e one-liner in the Reviewer Test Plan. Its state was confirmed by an independent TCP probe before every cell (listening when held, ECONNREFUSED when free), never inferred from listen() returning.

cell	arm	port 43190	suite	oracle	result
A1	base	free	container	vitest JSON counts	13/13 passed, 0 failed, exit 0
A2	base	held	container	vitest JSON counts + failure text	11/13 passed, 2 failed, exit 1 — `listen EADDRINUSE: address already in use 0.0.0.0:43190`
A3	head	free	container	vitest JSON counts	13/13 passed, 0 failed, exit 0
A4	head	held	container	vitest JSON counts	13/13 passed, 0 failed, exit 0
B1	base	held	attestation-worker	vitest JSON counts	29/29 passed, 0 failed
B2	head	held	attestation-worker	vitest JSON counts	29/29 passed, 0 failed

The 2 base reds are exactly the two container-mode tests (wires the gate in the actual boot3 startup… and opens the explicit container port with authenticated attestation), asserted by name, and head runs the same 13 tests as the base control (no test silently lost). One cell pair flips — A2 red, A4 green — and the other four cells are the controls that pin that flip to the port collision rather than to the arm. Witness: 01-ab-port-collision-base-vs-head.png.

B1 is a control worth reading: the sibling suite was already immune on base, because it already had the ephemeral-listen mock. That is the pattern this PR copies, and it confirms the mechanism rather than merely asserting it.

Mutation matrix — does the suite still hold down what it claims to?

Every mutant runs with port 43190 held, i.e. in the environment where head is known-green (A4/B2), so any red is attributable to the mutation. Runner hygiene: unmutated baseline green through the identical runner (42/42, exit 0); every anchor dry-run for exactly one occurrence; a process.stderr.write marker proving each mutant executed (v1 of this harness used console.error, which vitest's console interception swallows whole — measured 0 occurrences, while process.stderr.write passed through 3/3); every kill attributed to a named test and an expected message token; per-mutant wall-clock cap; file hashes verified restored after each mutant; tree clean and zero orphaned ppid=1 processes at the end. Witness: 02-mutation-matrix-kills-and-survivors.png.

mutant	target	what it changes	predicted	observed	counts
CTRL	production	`INVALID_BOOT_MESSAGE` text	KILLED	KILLED	22/42
M1-port	production	container bind port `43190` → `43191`	KILLED	KILLED	39/42
M2-host	production	container bind host `'0.0.0.0'` → `'127.0.0.1'`	KILLED	KILLED	39/42
M5-urlport	production	`ready.url` port hard-coded to `43190`	KILLED	KILLED	36/42
M9-urlhost	production	`ready.url` host from `address.address`	KILLED	KILLED	41/42
M3-test-host-fwd	container test	mock forces `'127.0.0.1'` again	SURVIVED	SURVIVED	42/42
M4-test-host-fwd	attestation test	mock forces `'127.0.0.1'` again	SURVIVED	SURVIVED	42/42
M10-combo-container	container test + production	M3 and M9 together	SURVIVED	SURVIVED	42/42
M11-combo-attest	attestation test + production	M4 and M9 together	KILLED	KILLED	41/42
M6-drop-mock-gate-test	container test	delete `mockEphemeralListen()` from the gate test	KILLED	KILLED	41/42
M7-drop-mock-port-test	container test	revert the explicit-port test to a plain spy	KILLED	KILLED	41/42

Kill attribution (named assertion, expected token present):

M1-port and M2-host both redden Managed Runtime container entry opens the explicit container port with authenticated attestation with expected "spy" to be called with arguments: [ 43190, '0.0.0.0' ], plus the two it.each ACK cases in the sibling suite. This is the PR's own claimed behavioural witness, and it holds.
M5-urlport reddens the same test at expected 'http://127.0.0.1:43190' to be 'http://127.0.0.1:38443' — so the rewritten ready.url assertion is not vacuous: it still pins that production derives the port from the bound socket rather than a constant.
M6/M7 each redden exactly the test whose mock was removed, with listen EADDRINUSE: address already in use 0.0.0.0:43190. Both hunks of the fix are individually load-bearing.

The combination row is the interesting one

M3 and M4 survived alone, which a one-row-per-guard matrix would file as two coverage gaps. They are not. M9 (production derives ready.url's host from address.address) is killed by the container test — but kill it again with the container mock also forced back to loopback (M10) and it survives at 42/42. Forcing loopback in only the sibling file (M11) leaves the kill intact.

So the host forwarding in managed-runtime-container.test.ts is load-bearing precisely as the new comment says: when the socket binds 127.0.0.1, production's hard-coded http://127.0.0.1: and http://${address.address}: are indistinguishable, and the host assertion loses its teeth. The forwarding in managed-runtime-attestation-worker.test.ts contributes no kill (M4 survived; M11 killed without it).

Upgraded from inferred to measured with a bind-host witness (bind-host-witness.mjs, 13/13): instrumenting each mock with a 'listening' listener that reports the kernel-bound address, without changing its behaviour —

variant	requested	kernel-bound address
head as shipped	`[43190,"0.0.0.0"]`	`0.0.0.0` on ephemeral ports 43427 / 36413 / 44843 / 41905
forced loopback (pre-commit-2)	`[43190,"0.0.0.0"]`	`127.0.0.1` on ephemeral ports 39213 / 45615 / 39049 / 39965

Both variants stay 42/42 green while instrumented, and the non-container workers in the same suites correctly bind 127.0.0.1:0 in both (4 of 5 recorded binds request 43190). The mock's host argument really does control the bound interface, and the port is ephemeral either way — which is the whole fix.

Reading the M5 row correctly

M5 shows 6 reds, but only one is the intended witness. Hard-coding ready.url to port 43190 sends other tests' fetch(worker.ready.url) at my port holder rather than at their worker, which is what reddens does not accept connections on other local addresses and the four STACK_TRACE_ERROR rows. That is an artefact of combining this particular mutant with a held 43190, not a property of the PR. The intended kill — the container test at line 332 — fired with the expected token.

Reviewer Test Plan, step by step

plan step	performed?	result
hold 43190 with a throwaway listener, run the container suite, expect 2 `EADDRINUSE` failures before the change	yes	cell A2: 11/13, 2 failed, exact message `listen EADDRINUSE: address already in use 0.0.0.0:43190`, and the two reds are exactly the two container-mode tests
…all 13 pass after the change	yes	cell A4: 13/13, exit 0
run the file normally with the port free — 13 pass	yes	cells A1 (base) and A3 (head): 13/13 both
run the pair of container-mode suites — 42 passed	yes	mutation-matrix baseline, same runner: 42/42 passed, exit 0
mutating the source bind port away from 43190 reddens `opens the explicit container port…` at `toHaveBeenCalledWith(43190, '0.0.0.0')`	yes	M1-port: that test red with `expected "spy" to be called with arguments: [ 43190, '0.0.0.0' ]`

Every step was performable; none was structurally unreachable. One deviation: the port holder was an in-process net server inside the harness rather than a separate node -e process — same bind, and its state was TCP-probed before each cell instead of assumed.

Findings

No blocking findings. Two Suggestion-level observations, both measured and bounded.

S1 — the port/host assertion is no longer scoped to the first `listen` call

expect(listen).toHaveBeenCalledWith(43190, '0.0.0.0') passes if any recorded call carried those arguments. The base assertion read listen.mock.results[0]?.value?.address(), i.e. the first call specifically. Today the explicit-port test starts exactly one worker, so the two forms are equivalent and M1/M2 confirm the assertion has teeth. If a future edit starts a second server in that test, the unscoped form could pass on the wrong one. expect(listen.mock.calls[0]).toEqual([43190, '0.0.0.0']) would keep the same strength and the scoping. Not a defect as shipped, and it matches the sibling suite's pre-existing style, so consistency argues the other way.

S2 — commit 2's host forwarding is inert in the sibling suite and widens its bind interface there

Measured: M4 (revert the forwarding in managed-runtime-attestation-worker.test.ts) survives 42/42, and M11 shows the container test still kills the production mutation without it — so that file's forwarding buys no detection power. The bind witness shows what it does change: that suite's container-mode ACK worker bound 127.0.0.1:<ephemeral> before and binds 0.0.0.0:<ephemeral> now. On a shared CI host that is a wider interface for the lifetime of the test. Ephemeral port, test-scoped, authenticated routes, and identical to what production does in container mode — so this is a note, not a risk finding. Worth knowing because the forwarding is load-bearing in the container file (M10) and merely stylistic in this one; if a reviewer ever "simplifies" the pair back to forced loopback, only the container file's copy would regress, and only against a ready.url-host mutation.

Accepted tradeoff, correctly described by the PR

Head no longer proves a real bind on 43190 itself — base asserted the kernel-accepted {address: '0.0.0.0', port: 43190}. What survives: the requested (43190, '0.0.0.0') (M1, M2 kill it), a real kernel bind on the requested host at an ephemeral port (bind witness), and real HTTP against it (the test still asserts 401 unauthenticated then 200 authenticated, and M6/M7 show the mock is a thin port override over a real bind, not a stub). The lost piece is exactly what made the tests flaky, and the PR's Risk & Scope section says so plainly.

Not covered

Full packages/cli unit suite (1234 test files). Ran the affected directory src/serve instead: 310 files passed / 310, 13602 tests passed, 0 failed, 59 pending (pre-existing skips), exit 0, and both changed files are among the 310 collected. 03-serve-gate-and-results-ledger.png.
Per-commit attribution. The snapshot lists 3 commits (6991d18b, 410f707f, 39d9dd57); the depth-2 checkout makes only the merge reachable, so git rev-list HEAD^1..HEAD^2 returns 1. Everything above verifies the aggregate HEAD^1..HEAD diff. Commit 2's effect is still isolated behaviourally, via M3/M4/M10/M11.
What this PR's own CI actually executed. No GitHub token in this job, so no check-run logs: whether the failing lane was reproduced, whether any -t filter matched zero tests, and whether the lane checked out the branch or the merge ref are all unverified here. The merge-ref question is settled locally — HEAD's parents are exactly the snapshot's baseRefOid and headRefOid, so every cell above ran on the trial merge; no separate merge arm was needed. Depth 2 does prevent listing what main added since the PR's own merge-base.
macOS and Windows. The PR marks both ⚠️ and this container is Linux only. Note the process.platform !== 'linux' branch in decodes boot v3 only through the container file… is therefore not exercised here either.
The real 43190 bind in production container startup — unchanged by this PR and untested here, as the PR states.
packages/sdk-java, which also references 43190 (WorkspaceCsiRuntimeIdentity, KubernetesRuntimeProvisioner, the broker README). QWEN_VERIFY_JAVA is unset and the container has no JDK, so nothing Java was compiled or run.
"No other test binds a hard-coded port" is a static census, not an empirical one. Measured over repo source with node_modules excluded: 224 .listen(<numeric literal>) call sites, and every one passes 0 (ephemeral) except scripts/tests/managed-agent-dev.test.js:335, which binds a Vite stand-in on fixed 5174 — the one live sibling of this bug class the census found, outside packages/cli and not audited further here. The 43190 site is invisible to that grep because it is a ternary (containerMode ? 43190 : 0), which is why it was censused separately: 43190 appears in exactly one production file and two cli test files, and both test files now mock listen. The only other fixed-port listen in the repo is oauth-provider.ts's OAUTH_REDIRECT_PORT (7777), whose test asserts expect(mockHttpServer.listen).toHaveBeenCalledWith({port: 7777, …}) against a mock; daemon-update-restart.test.ts's 48123 is a stubbed getPort() return value asserted in spawned argv, and that file's only real bind is server.listen(0, '127.0.0.1', …). I did not run the full cli suite under a held 43190 to confirm any of this empirically, and the PR itself scopes the audit out.

Methodology

All work ran in the CI verify container (node:22-bookworm, /__w/qwen-code/qwen-code, no credentials) against the pre-built merge ref, with the base arm in a scratch worktree at tmp/base-tree (HEAD^1) whose node_modules and dist were hardlinked from head and whose internal @qwen-code/* links were realpath-asserted into the base tree; npm run generate gave it its own git-commit.ts. Four harnesses drove the code, all mock-free with respect to the unit under test — real vitest workers, real node:http servers, real kernel binds, real loopback fetch, and a real TCP port holder probed independently before every cell: ab-port-collision.mjs (6 cells, 16 assertions), mutation-matrix-v2.mjs (baseline + 11 mutants, 69 assertions), bind-host-witness.mjs (2 variants, 13 assertions), gates.mjs + gate-serve-assert.mjs (12 assertions). Gates: prettier --check and eslint clean on both changed files, each proven live by planting a violation in the reviewed file and watching it be reported (unusedGateProbe named by no-unused-vars; Code style issues found), then restoring; tsc --noEmit for packages/cli clean; src/serve suite green. Raw per-cell stdout/stderr, per-mutant logs, the vitest JSON reports, and the gate logs are in raw-logs/; harnesses are .mjs files in this directory and rerun as-is. Two harness defects found and fixed mid-round, both preserved on disk rather than overwritten: mutation run 1 deadlocked in teardown (holder.close() awaited before closeAllConnections(), Node exit 13, hygiene rows lost — mutation-run1-incomplete-teardown-bug.log) and reported one spurious FAIL because its control token exceeded vitest's … truncation; gate-serve-assert-run1-ansi-bug.log matched ANSI-coloured bytes literally and called a 310/310 pass a failure. Run 2 of each is authoritative and every number above is generated from those files. The worktree was removed after the cells were captured and git status --porcelain is empty.

Flakiness gate log


rounds=5 files=2 skipped=0
file packages/cli/src/serve/managed-runtime-attestation-worker.test.ts: (cd packages/cli) npx --no-install vitest run ./src/serve/managed-runtime-attestation-worker.test.ts
file packages/cli/src/serve/managed-runtime-container.test.ts: (cd packages/cli) npx --no-install vitest run ./src/serve/managed-runtime-container.test.ts


per-file results (P=pass F=fail I=infra-exit, one letter per run):
  packages/cli/src/serve/managed-runtime-attestation-worker.test.ts: PPPPP
  packages/cli/src/serve/managed-runtime-container.test.ts: PPPPP

verdict: pass
summary: 2 changed test file(s) x 5 identical rounds, no divergence

--- per-invocation detail (full copy in the artifact) ---
round 1 · packages/cli/src/serve/managed-runtime-attestation-worker.test.ts: P (exit 0)
round 1 · packages/cli/src/serve/managed-runtime-container.test.ts: P (exit 0)
round 2 · packages/cli/src/serve/managed-runtime-attestation-worker.test.ts: P (exit 0)
round 2 · packages/cli/src/serve/managed-runtime-container.test.ts: P (exit 0)
round 3 · packages/cli/src/serve/managed-runtime-attestation-worker.test.ts: P (exit 0)
round 3 · packages/cli/src/serve/managed-runtime-container.test.ts: P (exit 0)
round 4 · packages/cli/src/serve/managed-runtime-attestation-worker.test.ts: P (exit 0)
round 4 · packages/cli/src/serve/managed-runtime-container.test.ts: P (exit 0)
round 5 · packages/cli/src/serve/managed-runtime-attestation-worker.test.ts: P (exit 0)
round 5 · packages/cli/src/serve/managed-runtime-container.test.ts: P (exit 0)

Evidence images

Harness scripts and raw logs are in the workflow run artifacts (7-day retention).

— Qwen Code · sandboxed verification

qwen-code-review-bot

LGTM, looks ready to ship. ✅

….png

wenshao · 2026-10-10T01:59:08Z

🔍 Local maintainer verification — verdict: merge-ready ✅

14,102 assertions checked (tally in Methodology), 0 unexpected failures.
Verified head: 39d9dd574a4101101fdb2f451ab0d18fdbf7a45b against merge-base c0c697c8a3d7d0460d37c497b76d52968c9216f7 (freshly fetched origin/main).
Environment: macOS 15.7.7 (arm64), Node.js v22.23.1.

🇨🇳 中文摘要

结论:可以合并。

这是一个纯测试 PR(仅 2 个测试文件,+24/−8,无生产代码改动),修复 issue Main CI failed: Qwen Code CI — src/serve/managed-runtime-container.test.ts > … > wires the gate in the actual boot3 startup while preserving… (+1 more) #13775 的 CI 抖动:两个 container-mode 测试在共享 CI 主机上真实绑定固定端口 43190,邻居进程占用时以 EADDRINUSE 失败。
A/B 实证:在占用 43190 的进程存活时,base 版测试文件复现了与 CI run 37925143593 完全一致的失败签名(2 失败 / 11 通过,listen EADDRINUSE: address already in use 0.0.0.0:43190,失败测试名逐个相符);同一占用进程下,PR 版 13/13 全部通过。端口空闲时两套件 42/42 通过。
变异见证:将生产代码绑定端口 43190→43199,opens the explicit container port with authenticated attestation 如期在 toHaveBeenCalledWith(43190, '0.0.0.0') 断言处失败——证明改后的测试仍在守卫请求端口,牙齿还在。
门禁:构建 ✅、typecheck 0 错误 ✅、eslint 对两个改动文件 ✅(先用植入的 debugger; 证明了 lint 门禁存活)、src/serve/ 全目录连带回归 13,599 通过 / 3 个失败——3 个失败均位于本 PR 未触碰的文件(无任何固定端口引用),单独重跑 443/443 全绿,签名为超时/临时目录竞态,与本 PR 无关。
额外价值:作者自测矩阵中 macOS 为 ⚠️ 未测,CI 的 macOS 测试作业在本 PR 上被跳过;本次验证在 macOS 15.7.7 (arm64) 上完成,补上了该平台空白。
未覆盖:Windows 平台;生产环境真实 43190 绑定(未改动,按设计不在本 PR 测试范围);其他测试套件的固定端口使用未审计。

What the PR changes

Two test files only, no production code (+24/−8): packages/cli/src/serve/managed-runtime-container.test.ts gains a mockEphemeralListen() helper that spies Server.prototype.listen, keeps the requested (43190, '0.0.0.0') arguments observable for assertions, but binds port 0 (kernel-assigned ephemeral) with the remaining arguments forwarded; the two container-mode tests use it instead of really binding 43190. packages/cli/src/serve/managed-runtime-attestation-worker.test.ts updates its pre-existing ephemeral-listen mock from a hard-coded [0, '127.0.0.1'] to [0, ...args.slice(1)], forwarding the requested host — the same faithful-mock pattern.

A/B proof (port 43190 held by a throwaway `node` process on `0.0.0.0`)

Run	Result	Signature
Base test files (merge-base `c0c697c8a3`), port held	❌ 2 failed / 11 passed	`listen EADDRINUSE: address already in use 0.0.0.0:43190` — byte-identical to the CI failure in run 37925143593 (confirmed in that run's logs), failing tests exactly the two named in #13775
PR head, port held	✅ 13/13 passed	flake mechanism removed
PR head, port free	✅ 13/13; pair with attestation-worker suite 42/42	no regression on the normal path

The A/B used one built worktree at the PR head with only the two test files swapped to their base versions in place; git status verified clean after each swap/restore.

Mutation witness (the modified test still has teeth)

Mutating the production bind in managed-runtime-attestation-worker.ts (containerMode ? 43190 : 0 → 43199) is killed by opens the explicit container port with authenticated attestation failing at expect(listen).toHaveBeenCalledWith(43190, '0.0.0.0') (line 330) — 1 mutant, 1 kill. The requested-port guard survives the move from "assert the real bind" to "spy the request".

Gates

Gate	Result
`npm run build` (worktree)	✅ all packages
`npm run typecheck`	✅ 0 errors
eslint on the 2 changed files	✅ clean; gate liveness proven first (planted `debugger;` fired `no-debugger`)
Collateral sweep: all of `packages/cli/src/serve/` (310 files)	13,599 passed / 3 failed in 3 files untouched by this PR — `hosted-harness-session` (409-vs-204), `hosted-hook-session` (15 s test timeout), `orchestrator` (ENOTEMPTY tmpdir race). None bind fixed ports; all 3 pass on an isolated re-run (443/443), i.e. load/parallelism flakes unrelated to this change

Code review notes

The helper mirrors the sibling attestation-worker suite's established pattern (the PR description's claim checks out in the diff).
Production container-mode bind (containerMode ? 43190 : 0, containerMode ? '0.0.0.0' : '127.0.0.1', managed-runtime-attestation-worker.ts:292-295) is unchanged — only the tests stop really binding the fixed port.
The new ready.url assertion derives the expected port from the actually bound address while production hard-codes the 127.0.0.1 host (managed-runtime-attestation-worker.ts:313); the attest round-trip in the test still exercises the real listener over the ephemeral port. The helper's comment correctly explains why only the port is overridden (forcing loopback would weaken the host dimension).
[0, ...args.slice(1)] faithfully forwards host/backlog/callback arguments in both suites.

Not covered

Windows (CI skipped Test (windows-latest, Node 22.x) on this PR; not run locally). macOS is covered by this report; the author's own matrix had macOS untested and CI skipped Test (macos-latest, Node 22.x) as well, so this run fills that gap.
The real production 43190 bind in container startup — unchanged and intentionally untested here.
Other suites' fixed-port usage — not audited (out of scope, as the PR states).

Methodology

Worktree at 39d9dd574a (installed with the shared pnpm store, built, workspace symlink verified to resolve inside the tree — no cross-tree leak). A/B by in-place swap of the two test files to their merge-base versions and back, with the port collision produced by node -e "require('node:net').createServer().listen(43190, '0.0.0.0', ...)" held throughout. CI signature cross-checked against run 37925143593 logs. Assertion tally: 14,097 unit-gate passes (42 focused + 13 head-under-contention + 13,599 collateral + 443 isolation re-run) + 4 harness assertions (2 predicted red signatures, 1 CI signature match, 1 lint-liveness plant) + 1 mutation kill = 14,102.

Evidence captures

A-side: base test files, port held — 2 failed with EADDRINUSE 0.0.0.0:43190 (CI signature), holder visible in lsof:

B-side: PR head, same port still held — 13/13 passed:

Mutation: production 43190 → 43199 killed by the spy assertion, then restored:

Full terminal flow of all three arms:

Local verification performed and posted by @wenshao's maintainer tooling; artifacts (logs, assertions.json, verdict.txt) retained locally under tmp/pr13778-verify-20261010-092223/.

yiliang114

Re-reviewed at head 39d9dd5 after the branch picked up main. The only new in-PR commit is 410f707: the ephemeral-listen mock now overrides only the port and forwards the requested host, so the ready.url host assertion is no longer self-referential while the EADDRINUSE fix is preserved. No blocking findings.

qwen-code-dev-bot · 2026-10-10T03:14:23Z

🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下：

Autofix round: no action required

No actionable feedback arrived since the last evaluation (2026-10-09T21:33:47Z), so this round made no code changes.

What the feedback contained

Inline comments: none.
Reviews: none.
Issue-level comments: two, neither requesting changes:
- An automated qwen-triage:verify status notice that sandboxed verification is running — informational only.
- A local maintainer verification report by @wenshao with verdict merge-ready ✅ (14,102 assertions checked, 0 unexpected failures against head 39d9dd574a). It confirms the A/B reproduction of the original EADDRINUSE 0.0.0.0:43190 flake on the base test files, the fix under port contention, the mutation witness proving the requested-port assertion still has teeth, and green build/typecheck/lint gates. No changes were requested.
Failed checks: none. Still-red checks: none.
Base conflict: none flagged (--conflict false); the branch already merges cleanly with origin/main.

Disposition

With no Required findings, no Optional suggestions, no failed checks, and no conflict to resolve, there was nothing to implement, decline, defer, or escalate. The PR remains as verified: a test-only change (+24/−8 across packages/cli/src/serve/managed-runtime-container.test.ts and packages/cli/src/serve/managed-runtime-attestation-worker.test.ts) that stops the two container-mode tests from really binding fixed port 43190 while keeping the requested-bind assertions observable via a Server.prototype.listen spy.

Verification

No code changed this round, so no verification commands were run. Existing state relied upon:

Maintainer local verification on head 39d9dd574a (see the PR comment): build ✅, typecheck ✅ (0 errors), eslint on both changed files ✅, focused suites 13/13 under port contention and 42/42 uncontended, 1/1 mutation killed.

中文说明

Autofix 本轮:无需处理

自上次评估(2026-10-09T21:33:47Z)以来没有收到可操作的反馈,因此本轮未做任何代码改动。

反馈内容

行内评论: 无。
Review: 无。
Issue 级评论: 两条,均未要求修改:
- 一条自动化的 qwen-triage:verify 状态通知,表示沙箱验证正在运行——仅为信息性通知。
- @wenshao 发布的本地 maintainer 验证报告,结论为 merge-ready ✅(基于 head 39d9dd574a 共检查 14,102 条断言,0 个意外失败)。报告确认了:在 base 版测试文件上 A/B 复现了原始的 EADDRINUSE 0.0.0.0:43190 抖动;端口被占用时修复后测试全部通过;变异见证证明请求端口的断言仍然有牙齿;构建/typecheck/lint 门禁全绿。未提出任何修改要求。
失败的检查: 无。持续失败的检查: 无。
与 base 的冲突: 未标记(--conflict false);分支当前可与 origin/main 干净合并。

处理结论

没有 Required 发现、没有 Optional 建议、没有失败的检查、也没有需要解决的冲突,因此本轮没有任何需要实现、拒绝、延后或升级的事项。PR 维持已验证的状态:一个纯测试改动(跨 packages/cli/src/serve/managed-runtime-container.test.ts 与 packages/cli/src/serve/managed-runtime-attestation-worker.test.ts 共 +24/−8),通过 Server.prototype.listen 间谍让两个 container-mode 测试不再真实绑定固定端口 43190,同时保持对请求绑定参数的断言可观测。

验证

本轮没有代码改动,因此未运行任何验证命令。所依据的现有状态:

基于 head 39d9dd574a 的 maintainer 本地验证(见 PR 评论):构建 ✅、typecheck ✅(0 错误)、对两个改动文件的 eslint ✅、端口占用下聚焦套件 13/13 通过、无占用时 42/42 通过、1/1 变异被杀死。

Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.25.0

Resolve the managed-runtime-container.test.ts overlap with QwenLM#13778 (merged): both PRs add an ephemeral-listen mock for the same port conflict. Keep main's mockEphemeralListen (host-forwarding shape) and drop this PR's duplicate listenOnEphemeralPort; the remaining delta is the boot3 test now also asserting the requested (43190, '0.0.0.0') bind arguments. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>

qwen-code-review-bot · 2026-10-11T11:42:53Z

Released in v0.25.1.

test(cli): bind ephemeral loopback port in container-mode tests (#13775)

6991d18

Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>

github-actions Bot added the review/self-reported The linked issue was opened by the PR author (self-reported) label Oct 9, 2026

qwen-code-dev-bot mentioned this pull request Oct 9, 2026

Fleet Shepherd Dashboard #11954

Open

yiliang114 previously approved these changes Oct 9, 2026

View reviewed changes

qwen-code-review-bot previously approved these changes Oct 9, 2026

View reviewed changes

qwen-code-review-bot reviewed Oct 9, 2026

View reviewed changes

Comment thread packages/cli/src/serve/managed-runtime-container.test.ts Outdated

test(cli): forward the requested bind host in ephemeral listen mocks (#…

410f707

…13775) Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>

qwen-code-dev-bot dismissed stale reviews from qwen-code-review-bot and yiliang114 via 410f707 October 9, 2026 21:32

Merge branch 'main' into autofix/issue-13775

39d9dd5

qwen-code-review-bot approved these changes Oct 10, 2026

View reviewed changes

wenshao added a commit to wenshao/qwen-code that referenced this pull request Oct 10, 2026

evidence: PR QwenLM#13778 verification pr13778-a-base-red-port-held.png

f98174e

wenshao added a commit to wenshao/qwen-code that referenced this pull request Oct 10, 2026

evidence: PR QwenLM#13778 verification pr13778-b-head-green-port-held…

344a5f9

….png

wenshao added a commit to wenshao/qwen-code that referenced this pull request Oct 10, 2026

evidence: PR QwenLM#13778 verification pr13778-mutation-kill.png

bda0184

wenshao added a commit to wenshao/qwen-code that referenced this pull request Oct 10, 2026

evidence: PR QwenLM#13778 verification pr13778-full-flow.png

7a80607

qwen-code-review-bot mentioned this pull request Oct 10, 2026

test(managed-agent): widen HostedHarnessMySqlIT lifecycle budgets for CI MySQL stalls (#13780) #13783

Merged

yiliang114 approved these changes Oct 10, 2026

View reviewed changes

yiliang114 added this pull request to the merge queue Oct 10, 2026

Merged via the queue into main with commit ad91df5 Oct 10, 2026
61 checks passed

qwen-code-dev-bot mentioned this pull request Oct 10, 2026

fix(cli): bound managed function-hook module evaluation and keep hold-fenced owners recoverable #13243

Merged

yiliang114 mentioned this pull request Oct 10, 2026

test(cli): avoid port conflicts in managed runtime container tests #13569

Merged

wenshao mentioned this pull request Oct 10, 2026

fix(runtime): retain CSI mount identity through directory resolution #13772

Merged

qwen-code-review-bot mentioned this pull request Oct 12, 2026

feat(core): account tool result sizes from producer to injection #13652

Closed

Conversation

qwen-code-dev-bot commented Oct 9, 2026

What this PR does

Why it's needed

Reviewer Test Plan

How to verify

Evidence (Before & After)

Tested on

Environment (optional)

Risk & Scope

Linked Issues

这个 PR 做了什么

为什么需要

评审验证计划

如何验证

前后对比证据

测试平台

环境(可选)

风险与范围

关联 Issue

Uh oh!

qwen-code-dev-bot commented Oct 9, 2026

Autofix E2E Report — Issue #13775

Summary

Root cause

Reproduction (before the fix)

Fix

Verification

Autofix E2E 报告 — Issue #13775

摘要

根因

复现(修复前)

修复

验证

Uh oh!

qwen-code-review-bot commented Oct 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qwen-code-review-bot commented Oct 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qwen-code-review-bot commented Oct 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code review

Test evidence

代码审查

测试证据

Uh oh!

qwen-code-review-bot commented Oct 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qwen-code-review-bot commented Oct 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🩺 serve daemon A/B

health-deep-with-session

Uh oh!

yiliang114 left a comment

Choose a reason for hiding this comment

Uh oh!

qwen-code-review-bot left a comment

Choose a reason for hiding this comment

Uh oh!

qwen-code-review-bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

qwen-code-dev-bot commented Oct 9, 2026

Uh oh!

qwen-code-dev-bot commented Oct 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qwen-code-dev-bot commented Oct 9, 2026

Round summary

Feedback dispositions

Reproduction and mutation probes

Other feedback

Verification

本轮总结

反馈处置

复现与变异探针

qwen-code-review-bot commented Oct 9, 2026 •

edited

Loading

qwen-code-review-bot commented Oct 9, 2026 •

edited

Loading

qwen-code-review-bot commented Oct 9, 2026 •

edited

Loading

qwen-code-review-bot commented Oct 9, 2026 •

edited

Loading

qwen-code-review-bot commented Oct 9, 2026 •

edited

Loading

`health-deep-with-session`

qwen-code-dev-bot commented Oct 9, 2026 •

edited

Loading

qwen-code-review-bot commented Oct 10, 2026 •

edited

Loading

S1 — the port/host assertion is no longer scoped to the first `listen` call

A/B proof (port 43190 held by a throwaway `node` process on `0.0.0.0`)