Repository navigation
fix(ci): cancel a destroyed merge group's queued Check run - #6105
Conversation
Co-Authored-By: GPT-6.1 <noreply@openai.com>
Keep one Check job and one dispatch; move feature permutations and optimized WASM builds to nightly and release PRs. Use dev-profile binding checks while preserving optimized Dart benchmarks. Co-Authored-By: GPT-6 <noreply@openai.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
GitHub never cancels a merge group's workflow run when the group is
destroyed, for example when an entry ahead leaves and the groups behind it
are rebuilt on new refs. On the single queue runner those stale runs stay
queued ahead of the live groups, which then pass the 60-minute check
timeout and get removed, rebuilding the groups behind them again.
Trigger Check on the merge_group `destroyed` activity too. Its run shares
the group's queue ref, so the existing `check-${{ github.ref }}`
concurrency group cancels the stale run, and the job skips itself.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 20 minutes. View limit details
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
WalkthroughThe pull request combines CI lint and test dispatch in one Check job, adds a reusable workflow for Rust feature and JavaScript/WebAssembly checks, and removes feature permutations from Rust change selection. It also adds configurable WebAssembly profiles and changes Dart checkout builds to use the development profile while benchmarks use release-profile bindings. Related workflow tests and CI documentation are updated. Priority: ➖ Normal Merge Risk: ⚪ Minimal · up to
|
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Docstring Coverage |  |
Docstring coverage is 3.23% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 31 functions across 15 files. (16 skipped:… | Write docstrings for the functions missing them to satisfy the coverage threshold. |
-
Check name Status Explanation Title check The title clearly describes the main merge-queue fix: canceling queued Check runs when GitHub destroys a merge group. Description check The description directly explains the stale merge-group run problem, the destroyed-event solution, affected files, tests, validation, and known unrelated failures. Linked Issues check Check skipped because no linked issues were found for this pull request. Out of Scope Changes check Check skipped because no linked issues were found for this pull request.
Full details: Docstring Coverage
-
Explanation
Docstring coverage is 3.23% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 31 functions across 15 files. (16 skipped: 16 unsupported.)
Resolution
Write docstrings for the functions missing them to satisfy the coverage threshold.
✨ Finishing Touches
-
✨ Simplify code
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands.
Problem
The merge queue stalled for hours. GitHub never cancels a merge group's workflow run when it destroys the group. That happens whenever an entry ahead leaves the queue and the groups behind it are rebuilt on new
gh-readonly-queue/main/pr-<N>-<base>refs. Each ref is unique, socheck-${{ github.ref }}never matches the old run. All queue jobs run on one self-hosted runner, so the dead runs stay queued ahead of the live groups.Example: #6082's group was created at 21:56Z, but its Check job only started at 22:58Z (run). That is past the 60-minute
check_response_timeout_minutes, so the queue removed it withchecks_timed_outeven though the run passed. Each removal rebuilds the groups behind it and leaves another set of stale runs, so the queue livelocks. At 23:13Z five 22:59Z runs were again queued for branches GitHub had already deleted.Approach
Also trigger Check on the
merge_groupdestroyedactivity. Actions delivers it, although its trigger docs list onlychecks_requested. The webhook docs do define it. The destroyed run uses the same queue ref, so the existingcheck-${{ github.ref }}concurrency group cancels the stale run. The job then skips itself, like theclosedPR run already does, so it never needs a runner.destroyedalso fires (reasonmerged), but the run is already complete, so nothing is cancelled. The only effect is a skippedCheckon main's new HEAD SHA..github/actionlint.yamlignores that one message forcheck.ymlonly, until rhysd/actionlint#726 lands.sh/gh/queue.test.tsandsh/gh/setup.test.tsnow cover the trigger, the skip, and the shared concurrency key.Prior art: chapel-lang/chapel#29274 uses the same pattern. Its merge_group runs show each rebuilt group's old run going
cancelledwithin about two minutes of askippeddestroyed run on the same branch. See also the community discussion.Built on #6086, which is set to land first. Once it merges, this diff reduces to the
merge_grouptrigger, the jobif, the actionlint config, and the tests.Impact
Alternatives
merge_group.head_commit.messageworks with squash titles, but group names are capped at 400 characters. It is also fragile when a title is edited, and it only cancels if the PR is re-enqueued, not when the PR leaves the queue.if:on every step, oractions: writeto cancel itself.actions: writeand more code, and was reported to cancel unrelated push runs on the same SHA.Follow-ups
max_entries_to_build5 makes the last group wait behind four others, which can exceed the 60-minute timeout even without stale runs. Speculative builds add no throughput on one runner and are wasted on any failure. Setmax_entries_to_buildto the runner count (1 today), or raisecheck_response_timeout_minutesto cover the queue depth.bun sh/gh/queue.test.ts, which runs nightly, already fails on main:smoke.yml must skip main PRs, since #6046 moved smoke into the repo. This PR does not touch that.Validation:
actionlintandjust gh checkpass, and thebun test sh/gh/setup.test.tstests pass.bun sh/gh/queue.test.tspasses its new assertions before reaching the pre-existing smoke.yml failure.just checkpassed everything exceptbench/relay.test.py, which timed out at 15s under load. Run alone, it passes in 1.2s.(Written by Claude Opus 5.5)
🤖 Generated with Claude Code