Main CI failed: E2E Tests on b85d7c818555

[qwen-code-dev-bot]

A main-branch CI run failed on main before any test result was
reported, so this issue is tracked per commit.

• Workflow: E2E Tests
• Run: https://github.com/QwenLM/qwen-code/actions/runs/33096740046
• Run ID: 33096740046
• Commit: b85d7c8

This issue is labeled for autofix so the existing agent can create a repair PR.

[qwen-code-dev-bot]

🤖 Withdrawing the claim above — the automated fix attempt did not succeed; no further automated attempts will be made on this issue.

What the agent found, in case it helps a human contributor:

Autofix stopped on #10328: dominant root cause already merged; residual failure is pool-only and not reproducible or diagnosable from this environment

Blocker

Issue #10328 tracks E2E run 33096740046 on main commit b85d7c81. The two failing jobs fail only on ecs-qwen pool runners, only in shard 1/3, in both Linux legs. The job logs require admin rights (403 Must have admin rights to Repository on the logs endpoint), this agent has no GitHub credentials, and the closest local surrogate — the exact same shard command — passes twice, fully green. After tracing the evidence through its source, callers, and related history, no specific code-level hypothesis remains to implement or test, which is the objective stop condition. No commit was made.

Note: the issue body says the run failed "before any test result was reported". That is boilerplate — all setup steps (checkout, npm ci, build, bundle, sandbox image) succeeded; both jobs failed inside the Run E2E tests step with exit code 1.

What failed (evidence from the public API)

Run 33096740046 @ b85d7c81 (2026-08-27 17:07 UTC):

job	conclusion	job id	runner	Run E2E tests step
E2E Test (Linux) - sandbox:none - shard 1/3	failure	98603509757	ecs-qwen-runner-hk-j6c03lyei7s809zq1s6u-9	236 s, exit 1
E2E Test (Linux) - sandbox:docker - shard 1/3	failure	98603509893	ecs-qwen-run

中文说明

不会对该 issue 再做自动尝试。

Autofix 在 #10328 上停止：主要根因已合并修复；残余失败仅出现在 ecs-qwen 池中，本环境既无法复现也无法诊断

阻塞点

Issue #10328 跟踪的是 main 分支提交 b85d7c81 上的 E2E 运行 33096740046。两个失败的 job 只在 ecs-qwen 池 runner 上、只在 shard 1/3、且在 Linux 的两个 sandbox 分支上失败。job 日志需要管理员权限（日志接口返回 403 Must have admin rights to Repository），本 agent 没有任何 GitHub 凭据，而最接近的本地替代运行——完全相同的 shard 命令——两次运行全部通过。在把证据沿着其源码、调用方和相关历史逐一追踪之后，已经没有任何具体的、可以实现或可验证的代码层面假设，这正是客观停止条件。没有产生任何提交。

说明：issue 正文称该运行"在任何测试结果上报之前失败"。这是模板措辞——所有准备步骤（checkout、npm ci、build、bundle、sandbox 镜像）都成功了；两个 job 都是在 Run E2E tests 步骤内部以退出码 1 失败的。

失败详情（来自公开 API 的证据）

运行 33096740046 @ b85d7c81（2026-08-27 17:07 UTC）：

job	结论	job id	runner	Run E2E tests 步骤
E2E Test (Linux) - sandbox:none - shard 1/3	failure	98603509757	ecs-qwen-runner-hk-j6c03lyei7s809zq1s6u-9	236 秒，退出码 1
E2E Test (Linux) - sandbox:docker - shard 1/3	failure	98603509893	ecs-qwen-runner-hk-j6c03lyei7s809zq1s6u-12	251 秒，退出码 1
其余六个 job（Linux shard 2/3、3/3 两个分支；macOS 1/2、2/2）	success			164–267 秒

上一次运行 33092671484 @ 1637aa968b（即修复提交本身）呈现相同形态：none 1/3 与 docker 1/3 失败，docker 3/3 失败过一次（下一次运行通过了，因此那一个看起来是偶发），其余全绿。合并前的 dispatch 运行 33091085019 @ 1df2e1dc33（修复候选提交）在不同的池 runner（sg-12、64c-22）上显示出同样的 none-1/3 + docker-1/3 失败。因此这个残余失败横跨多个池宿主机、在三次运行中按 shard 确定性地出现，并且既早于已合并的修复存在、也在其之后继续存在。

两个失败步骤都很快（236 秒 / 251 秒），与通过的 shard（164–267 秒）相当，所以这是快速失败，而不是 5 分钟超时级别的卡死。check-run 注解只带有笼统的 "Process completed with exit code 1"；失败的测试名和断言只存在于需要管理员权限的日志中。

已排除的可能原因

1. goal-runtime 启动卡死（E2E: external-context mem0 tests hang at 'Connecting to MCP servers' on macOS and ecs-qwen pool (pass on ubuntu-hosted) #10272）在当前代码树上已经被修复。 该类问题（fix(cli): bound the goal-runtime startup wait and skip the no-op Bun memory relaunch #10128 将 Config.getGoalRuntimeReady() 的同步抛出提到了 try 之外，导致 TUI 冻结在 "Connecting to MCP servers..."）正是让全部 8 个 job 变红的原因。fix(cli): restore goal-less startup broken by the goal-runtime wait refactor #10290（提交 1637aa968b