You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(ci): never cancel a pull request's Queue check - #291
moq-dev/rind#289 made the required Queue job report the reusable build's result: needs: build with if: always() && github.event_name == 'merge_group'. On a pull request that job now waits for build to skip before it skips itself. The workflow-level concurrency group (cancel-in-progress: true) cancels a PR's run when a second event for the same PR arrives within seconds, such as synchronize from a push followed by edited from a body edit. The cancelled run's Queue check then reports cancelled, which fails the required check and blocks enqueueing.
Seen on moq-dev/quest#445, head adb28aa6: run 41683755363 had Queue cancelled while Queue build and Report Queue skipped, next to run 41683758122, which skipped normally. Both were created in the same second.
Approach
Drop the workflow's concurrency group and say why in a comment:
Merge groups each have their own ref, and dispatches each have their own head, so the group never coordinated a merge-group run with another. Its only effect was cancelling a PR's duplicate run, which is the bug.
With no group, nothing cancels a pull request's run, so its Queue check always ends skipped.
The merge-group path is unchanged: Queue still runs under always() and fails when the build fails or is cancelled, so a skipped context can't pass the group.
Alternatives
cancel-in-progress: ${{ github.event_name != 'pull_request' }}: rejected. A group without cancel-in-progress still cancels a pending run when a newer one queues (GitHub docs on concurrency), so three quick events would still cancel the middle run's Queue.
Make Queue skip immediately off merge groups: not possible while it keeps needs: build, since a job waits for its needs before it evaluates if. always() is what keeps it running when the build is cancelled (status check functions). Dropping needs would lose the build's result.
The workflow-level concurrency group cancelled a pull request's run when a
second event for the PR arrived within seconds (a push, then a body edit).
Its `Queue` job, which waits on `build` before it skips, then reported
cancelled and failed the required check. Even without cancel-in-progress, a
group cancels a pending run, so drop the group: merge groups each have their
own ref, and a repeated dispatch only reports the same skipped context.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
No actionable comments were generated in the recent review.
Walkthrough
The workflow no longer groups runs by ref and dispatch SHA or cancels in-progress runs. Updated comments describe pull-request runs waiting on build before skipping, distinct merge-group refs, and repeated dispatches that may report the same skipped context.
Merge Risk: Minimal · up to 42e3e
This CI-only change removes automatic cancellation of earlier Queue checks. No actionable merge-blocking issue is established; it is ready to merge after normal checks.
Pre-merge checks: 5
Check name
Status
Explanation
Title check
The title clearly and concisely describes the main CI change: preventing pull request Queue checks from being cancelled.
Description check
The description directly explains the concurrency problem, the fix, its CI-only impact, and the expected behavior for pull requests and merge groups.
Docstring Coverage
No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentat…
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
No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 0 functions across 0 files. (1 skipped: 1 unsupported.)
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.
Run CodeRabbit Verify to test the changes in this pull request.
Recent review info
Run configuration
Source mode: Auto
Repository: Unavailable
Branch: Unavailable
File: No configuration file from this repository applied
Commit: Unavailable
Layers: Organization UI
Review profile: CHILL
Plan: Advanced
Run ID: 31bdda21-8098-408e-a0b5-b8d7052abda9
Commits
Reviewing files that changed from the base of the PR and between 0f946f1 and 42e3e3d.
Files selected for processing: 1
.github/workflows/queue.yml
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
moq-dev/rind#289 made the required
Queuejob report the reusable build's result:needs: buildwithif: always() && github.event_name == 'merge_group'. On a pull request that job now waits forbuildto skip before it skips itself. The workflow-levelconcurrencygroup (cancel-in-progress: true) cancels a PR's run when a second event for the same PR arrives within seconds, such assynchronizefrom a push followed byeditedfrom a body edit. The cancelled run'sQueuecheck then reports cancelled, which fails the required check and blocks enqueueing.Seen on moq-dev/quest#445, head
adb28aa6: run 41683755363 hadQueuecancelled whileQueue buildandReport Queueskipped, next to run 41683758122, which skipped normally. Both were created in the same second.Approach
Drop the workflow's
concurrencygroup and say why in a comment:Queuecheck always ends skipped.Queuestill runs underalways()and fails when the build fails or is cancelled, so a skipped context can't pass the group.Alternatives
cancel-in-progress: ${{ github.event_name != 'pull_request' }}: rejected. A group without cancel-in-progress still cancels a pending run when a newer one queues (GitHub docs on concurrency), so three quick events would still cancel the middle run'sQueue.Queueskip immediately off merge groups: not possible while it keepsneeds: build, since a job waits for its needs before it evaluatesif.always()is what keeps it running when the build is cancelled (status check functions). Droppingneedswould lose the build's result.Impact
Related
Review
quest review --base origin/main), gpt-6.1-sol, medium effort42e3e3dac5cdb52c50d4b0bb6f8c8e9d5f38fab3Follow-ups
(Written by Claude Opus 5.5)
🤖 Generated with Claude Code