ci(review): default review timeout to 180 minutes, allow up to 240 - #6706
Conversation
|
Thanks for the PR! Template looks good ✓ Problem: Observed operational issue — large PRs like #6680 routinely hit the 120-minute default and get a timeout comment asking the author to retry with Direction: Aligned. Raising the default to the existing cap removes a predictable fail-and-retry round trip without changing any upper bound. The 200-minute job-level budget still leaves 20 minutes of headroom for setup and fallback-comment posting. Size: Not applicable — only Approach: Clean and minimal. All three default-establishing values move together (dispatch input, script constant, dispatch fallback). No scope creep. The degradation path is correct: with default = cap, a timeout takes the "already used the maximum 180 minute timeout" branch instead of suggesting a retry at the same value. Exactly the right change. Moving on to code review. 🔍 中文说明感谢贡献！ 模板完整 ✓ 问题：已观测到的运维问题——#6680 等大型 PR 经常超过 120 分钟缺省值，超时后机器人会要求用 方向：对齐。将缺省值提高到现有上限，消除可预见的"失败-重试"往返，不改变任何上限。job 级 200 分钟预算仍留有 20 分钟余量用于环境准备和回退评论。 规模：不适用——仅触及 方案：干净且最小化。三处缺省值同步修改（dispatch 输入、脚本常量、dispatch 回退）。无范围蔓延。降级路径正确：缺省值等于上限后，超时会走"已使用最大 180 分钟超时"分支，而不是建议用相同值重试。改动恰到好处。 进入代码审查 🔍 — Qwen Code · qwen3.7-max |
wenshao
changed the title
|
Code review: Clean. Three value changes, all consistent, no new logic introduced.
No critical blockers. No AGENTS.md violations. Testing: N/A — this is a CI workflow configuration change with no TUI surface. There's nothing to drive in tmux. Verification is structural: YAML validity, value consistency across the three change sites, and correct degradation of the fallback comment path. All three check out. 中文说明代码审查： 干净。三处值修改，全部一致，无新增逻辑。
无阻断性问题。无 AGENTS.md 违规。 测试： 不适用——这是 CI 工作流配置变更，无 TUI 界面。tmux 中没有可驱动的内容。验证为结构性的：YAML 合法性、三处修改的值一致性、回退评论路径的正确降级。三项均通过。 — Qwen Code · qwen3.7-max |
|
This is a tight, well-motivated config change. The problem is real and observable — #6680 hit the 120-minute timeout and the only remedy was a manual retry at 180, which is already the cap. The fix is exactly what I would have done: move all three defaults to 180 so the fail-and-retry loop just doesn't happen. The degradation path works correctly too. A timeout at the new default (180) now produces "already used the maximum 180 minute timeout" instead of the useless "retry with Tradeoff is acknowledged and acceptable: reviews that would have failed at 120 minutes now occupy a runner for up to 60 more minutes. The 200-minute job budget still has 20 minutes of headroom. LGTM — approving. 中文说明这是一个紧凑、动机明确的配置变更。问题真实可观测——#6680 超过了 120 分钟超时，唯一的补救方式是手动以 180 重试，而 180 已经是上限。修复方案正是我会做的：将三个缺省值都改为 180，这样"失败-重试"循环就不会发生。 降级路径也正确。新的缺省值（180）超时后会产生"已使用最大 180 分钟超时"消息，而不是无用的"用 取舍已确认且可接受：原本在 120 分钟失败的 review 现在最多多占用 runner 60 分钟。200 分钟的 job 预算仍有 20 分钟余量。 LGTM — 批准。 — Qwen Code · qwen3.7-max |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
LGTM, looks ready to ship. ✅
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Reviewed — no blockers. Suggestions are inline.
| startsWith(github.event.review.body, format('@qwen-code /review{0}', '\n'))) && | ||
| needs.authorize.outputs.should_review == 'true')) | ||
| timeout-minutes: 200 | ||
| timeout-minutes: 260 |
There was a problem hiding this comment.
[Suggestion] The three-tier timeout architecture (default 180, max 240, job 260) requires these values to move together, but this relationship is undocumented. The 20-minute headroom between the validation cap (240) and the job-level timeout-minutes (260) exists so the shell timeout can kill the review process and let the error-reporting step run before GitHub's hard kill — this is non-obvious.
A future maintainer raising the cap to, say, 300 might not realize they also need to bump timeout-minutes to 320 to preserve that headroom. A one-line comment here would prevent that mistake.
| timeout-minutes: 260 | |
| # Must exceed the validation cap (currently 240) by enough margin for error reporting | |
| timeout-minutes: 260 |
— qwen3.7-max via Qwen Code /review
…LM#6706 timeout changes (QwenLM#6720) PR QwenLM#6706 updated review-pr workflow timeout values (job timeout to 260m, default to 180m, max to 240m) but did not update the corresponding test expectations, causing CI failures on all subsequent PRs.
What this PR does
Raises the default timeout for the automated PR review workflow from 120 minutes to 180 minutes, and raises the maximum allowed override from 180 to 240 minutes so
@qwen-code /review --timeout=240becomes available for the largest PRs. All three places that establish the default move together: theworkflow_dispatchinput default, the script-level default used by lifecycle and comment triggers, and the dispatch fallback value. The timeout-cap validation and the timeout fallback comment now reference 240, and the job-level timeout grows from 200 to 260 minutes to keep the same headroom (max review time plus setup and fallback-comment posting) established in #5961.Why it's needed
Large PRs routinely exceed the 120-minute default and fail with a timeout comment asking the author to retry with a longer timeout (see the timeout on #6680). Since retrying at the previous 180-minute maximum was the standard remedy, defaulting to it removes a predictable failure-and-retry round trip. Raising the cap to 240 keeps an escalation path available for reviews that exceed the new default instead of leaving the default and the ceiling at the same value.
Reviewer Test Plan
How to verify
DEFAULT_TIMEOUT_MINUTES, and the dispatch fallback all read 180.--timeout=240passes validation.--timeout=240, while a run that already used 240 states the maximum was reached.Evidence (Before & After)
N/A — CI workflow configuration change, no TUI surface.
Tested on
Environment (optional)
N/A — YAML-only change, validated by parsing the workflow file.
Risk & Scope
--timeout=240can hold a self-hosted runner slot for up to 4 hours plus headroom; genuinely hung reviews occupy the slot longer before the fallback comment posts.--timeout=override syntax, trigger authorization, or the resolve job.Linked Issues
N/A (motivated by the review timeout on #6680)
中文说明
本 PR 做了什么
将自动 PR review 工作流的缺省超时从 120 分钟提高到 180 分钟,并把允许的最大覆盖值从 180 提高到 240 分钟,使超大 PR 可以使用
@qwen-code /review --timeout=240。三处缺省值同步修改:workflow_dispatch输入的默认值、lifecycle 与评论触发使用的脚本级默认值,以及 dispatch 的回退值。超时上限校验和超时回退评论现在引用 240;job 级超时从 200 提高到 260 分钟,以保持 #5961 中确立的余量设计(最大 review 时长加环境准备与回退评论开销)。为什么需要
大型 PR 经常超过 120 分钟的缺省值,失败后机器人会留言要求作者用更长超时重试(见 #6680 上的超时)。既然按之前 180 分钟最大值重试就是标准处理方式,直接把缺省值设为 180 可以消除一次可预期的"失败-重试"往返。把上限提高到 240 则为超过新缺省值的 review 保留了升级手段,避免缺省值与上限相同而无路可退。
Reviewer 测试计划
如何验证
DEFAULT_TIMEOUT_MINUTES和 dispatch 回退值均为 180。--timeout=240可通过校验。--timeout=240重试;已使用 240 的运行会提示已达最大值。前后证据
N/A——CI 工作流配置变更,无 TUI 界面。
测试平台
环境(可选)
N/A——仅 YAML 变更,已通过解析工作流文件验证。
风险与范围
--timeout=240会让 self-hosted runner 槽位被占用最长 4 小时加余量;真正卡死的 review 在回退评论发出前占用时间更久。--timeout=覆盖语法、触发授权或 resolve job。关联 Issue
N/A(由 #6680 上的 review 超时引发)