CI perf (settings): 90-min merge-queue check timeout let one stuck check freeze main for 77 min
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
研究方向
Start by checking the merge queue ruleset value for check_response_timeout_minutes and read scripts/merge-queue-fail-fast.py for the referenced Gradle durations. Verify whether any merge-group tier runs those longer jobs, then choose 45 or 60 minutes accordingly. Done when the timeout is updated to the supported value and the merge queue retains enough time for its longest merge-group checks.
由索引模型根據 Issue 內容生成。
描述
The merge queue's check_response_timeout_minutes is 90 (ruleset 24668460). Merge-group CI takes far less than that. So when a required check never reports, the queue stays frozen for about 1.5 hours before it gives up.
What happened on 2026-10-22. The clippy check of queue head #1653 stayed in_progress after its job and its run had both finished successfully. Details are in #1660. Nothing merged from 17:38 to 18:55 UTC. Seven green entries waited behind it, then all of them were rebuilt after the timeout evicted #1653.
Merge-group CI durations today (CI workflow, success, created to completed):
| run | PR | duration |
|---|---|---|
| 39820221573 | #1651 | 8.5 min |
| 39820490126 | #1656 | 12.2 min |
| 39822385680 | #1663 | 12.3 min |
| 39822379065 | #1642 | 13.2 min |
| 39822377061 | #1640 | 13.7 min |
| 39822369515 | #1652 | 13.8 min |
| 39822372512 | #1653 | 14.1 min |
| 39824290078 | #1667 | 14.7 min |
| 39826164711 | #1664 | 10.1 min |
| 39826160345 | #1658 | 11.3 min |
The longest is under 15 minutes.
Suggestion (needs a repo admin): lower check_response_timeout_minutes from 90 to 45. That is about 3x the slowest run above, which leaves room for a runner backlog (see #1512) and still cuts a stall like today's roughly in half. Before changing it, check that no merge-group tier runs the ~45-minute Gradle legs that scripts/merge-queue-fail-fast.py mentions. If one does, 60 is the safer value.
Generated by Claude Code
- 主要語言
- Rust
- 星號
- 8
- 分支
- 1
- 平均合併
- 19 小時 9 分鐘
- 30 天內合併 PR
- 641
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 沒有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
SocketDev/socket-patch 的其他 Issue
-
agent:triaged bug bughunt pm:npm priority:p3 ux
難度 2/5 1-3 小時 新手友好度 75/100
SocketDev/socket-patch#1072 · 2 則留言 ·
維護者通常 1 天內回覆
-
agent:needs-human agent:triaged ci-perf priority:p3
難度 3/5 1-2 天 新手友好度 45/100
SocketDev/socket-patch#1720 · 4 則留言 ·
維護者通常 1 天內回覆
-
Nightly Windows test shards fail on temp-path spelling (RUNNER~1 vs canonical \\?\ paths)可能已有人在做 @mikolalysenko 於 2 天前認領。 未關閉agent:claimed agent:triaged ci-janitor priority:p3
難度 4/5 3-5 天 新手友好度 55/100
SocketDev/socket-patch#1689 · 6 則留言 ·
維護者通常 1 天內回覆
-
agent:triaged ci-janitor priority:p3
難度 3/5 1-2 天 新手友好度 55/100
SocketDev/socket-patch#1665 · 3 則留言 ·
維護者通常 1 天內回覆
-
agent:needs-human agent:triaged ci-janitor priority:p3
難度 4/5 1-2 天 新手友好度 18/100
SocketDev/socket-patch#1660 · 4 則留言 ·
維護者通常 1 天內回覆
查看 SocketDev/socket-patch 的全部 Issue
相似的 Issue
-
nn::linear: weight initialization depends on `bias` because the bias is created before the weight可能已有人在做 @monfortema 今天認領。 未關閉
難度 2/5 1-3 小時 新手友好度 72/100
LaurentMazare/tch-rs#1067 ·
-
難度 2/5 1-3 小時 新手友好度 70/100
FavioVazquez/mollify#62 ·
-
C-enhancement
難度 2/5 1-3 小時 新手友好度 68/100
obi1kenobi/cargo-semver-checks#1785 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 61/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 62/100
fendouai/awesome-deepseek-harness#125 ·
維護者通常 4 天內回覆