test: harden release timing-sensitive waits - #10615
Conversation
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
|
✅ Qwen Triage finished — CI landed green on ✅ Qwen Triage 已完成 —— |
|
Thanks for the PR! Template looks good ✓ Problem: observed, with direct evidence. Nightly release run #33361682601 failed the Direction: aligned — this unblocks the nightly release pipeline by stabilizing two timing-sensitive tests, and every behavioral assertion is preserved. No product-direction questions. Size: not applicable — test-only change: 2 test files, +5/−1, zero production lines. Approach: the scope is exactly the two flakes, nothing extra. Widening the Risk: no elevated risk signals — no production code or high-risk paths touched. Moving on to code review. 🔍 中文说明感谢贡献! 模板完整 ✓ 问题:已观测到,且有直接证据。Nightly 发布运行 #33361682601 的 方向:对齐——通过稳定两个时序敏感测试来解除 nightly 发布管线的阻塞,且全部行为断言均被保留。无产品方向问题。 规模:不适用——纯测试改动:2 个测试文件,+5/−1,生产代码零行。 方案:范围恰好是两个 flake,没有多余改动。扩大 风险:无升级风险信号——未触及生产代码或高风险路径。 进入代码审查 🔍 — Qwen Code · qwen3.8-max Reviewed at |
Code reviewNo blockers. I checked the two changes against their surroundings:
One observation, not blocking: the sibling Test evidence (PR's own CI + the release-run failures)Unattended run — I did not build or execute PR code. Two evidence sources:
A caveat that applies to any flake fix: one green run demonstrates the tests pass, not that the race is gone for good — only repeated runs (future nightlies included) show that. Nothing user-visible changes, so no live TUI verification applies. Final CI results for
One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行(取最新一次运行),省略 skipped,失败项排在最前。 中文说明代码审查无阻塞问题。两处改动均与上下文核对过:
一个非阻塞观察:相邻的 测试证据无人值守运行——未构建或执行 PR 代码。证据来自两处:发布运行 #33361682601 的 Flake 修复的固有注意点:一次绿色运行只能证明测试通过,不能证明竞态彻底消失,需要后续反复运行(含后续 nightly)验证。无用户可见变化,无需真机 TUI 验证。 — Qwen Code · qwen3.8-max Reviewed at |
|
Confidence: 5/5 — a minimal, well-evidenced flake fix: the two observed release failures map exactly onto the two waits it widens, assertions are untouched, and there is no production code in the diff. This is the kind of PR that should be easy: a real failure (nightly release #33361682601), a root cause that matches the log (a 500 ms polling budget and a one-frame settle that weren't enough on a loaded runner), and the smallest change that fixes it without weakening any check. Nothing in the diff reaches past the two failing tests, and the tradeoff — slower failure when a condition truly never arrives — is documented and bounded. My only standing note is the one inherent to flake fixes: durable stability shows itself over repeated runs, not one, so the next few nightlies are the real confirmation. Approval is deferred until CI lands green on this commit — the unit suite, integration tests, and web-shell visuals were still running at review time. 中文说明置信度:5/5 —— 最小且证据充分的 flake 修复:观测到的两个发布失败恰好对应它所加宽的两处等待,断言原样保留,diff 中没有任何生产代码。 这个 PR 很简单明了:真实的失败(nightly 发布 #33361682601)、与日志吻合的根因(500 ms 轮询预算和单帧等待在负载较高的 runner 上不够用),以及不削弱任何检查的最小修复。diff 没有超出两个失败测试的范围,取舍——条件确实永不出现时失败变慢——已说明且有界。唯一保留意见是 flake 修复的固有特性:持久稳定性要靠反复运行(接下来几次 nightly)证明,而不是一次运行。 批准将推迟到该提交的 CI 全部转绿后执行——审查时单元套件、集成测试和 web-shell visuals 仍在运行。 — Qwen Code · qwen3.8-max Reviewed at |
🖼️ web-shell visual previewRendered against a mock daemon (no real backend): the PR base vs this PR head Screenshots · before / after✅ No screenshot changes against the PR base. Full-resolution recordings (.webm) are attached to the workflow run. — Qwen Code · web-shell visuals |
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
LGTM, looks ready to ship — CI landed green after the review. ✅
|
Released in v0.23.0. |
What this PR does
This PR hardens the two timing-sensitive unit-test boundaries that blocked the nightly release. Agent View supervisor tests now keep their readiness polling bounded but tolerate shared-runner delays beyond 500 ms, and the Web Shell pagination scenario waits for React's render and anchor-cleanup frames to settle before starting each subsequent page.
Why it's needed
Nightly release run #33361682601 reached all test gates, but the quality job failed when one supervisor attach response arrived after the test helper's short polling budget and one pagination assertion ran before the previous load's animation-frame cleanup completed. Both integration jobs passed, the same commit's normal CI passed, and the publish job never ran. These waits preserve the existing behavioral assertions while removing assumptions about runner speed and single-frame scheduling.
Reviewer Test Plan
How to verify
Evidence (Before & After)
Before: release run #33361682601 failed the two targeted timing-sensitive tests and skipped publishing.
After: each targeted test passed 5/5 consecutive local runs; the surrounding Web Shell test file passed 158/158. UI verification: N/A because this changes test synchronization only and does not change rendered behavior.
Tested on
Environment (optional)
Node.js 22.22.0 and Vitest 3.2.7. The Agent View repetition used an ECS-style runner name so its existing worker limit was active.
Risk & Scope
ENOTEMPTYduring the full Agent View file run and passed immediately in isolation; this PR does not change that scenario.Linked Issues
Fixes #10608
中文说明
此 PR 的改动
此 PR 加固了阻塞 nightly 发布的两个时序敏感单测边界。Agent View supervisor 测试的就绪轮询仍然有明确上限,但现在可以容忍共享 runner 上超过 500 毫秒的延迟;Web Shell 分页场景会等待 React 渲染和锚点清理帧完全结束,再开始后续分页。
为什么需要这个改动
Nightly 发布运行 #33361682601 已进入全部测试门禁,但 quality job 中一个 supervisor attach 响应超过了测试 helper 的短轮询预算,另一个分页断言在上一轮加载的 animation-frame 清理完成前执行,因此失败。两个 integration job 都已通过,同一提交的常规 CI 也通过,publish job 从未执行。本改动保留原有行为断言,只移除对 runner 速度和单帧调度的假设。
Reviewer 测试计划
如何验证
证据(修改前与修改后)
修改前:发布运行 #33361682601 的两个目标时序敏感测试失败,发布被跳过。
修改后:两个目标测试分别连续执行 5 次,均为 5/5 通过;相邻的 Web Shell 测试文件 158/158 通过。UI 验证:N/A,因为本改动只调整测试同步,不改变渲染行为。
测试平台
环境(可选)
Node.js 22.22.0 和 Vitest 3.2.7。Agent View 重复验证使用了 ECS 风格的 runner 名称,因此启用了现有 worker 限制。
风险与范围
ENOTEMPTY,隔离后立即通过;本 PR 不修改该场景。关联 Issue
Fixes #10608