fix(ci): retry Auto Queue while mergeStateStatus is UNKNOWN, gate on approval and resolved threads#4678
Merged
Yicong-Huang merged 6 commits intoMay 2, 2026
Conversation
The AutoQueue workflow fires moments after a push to main, when GitHub has not yet recomputed mergeStateStatus for open PRs (often UNKNOWN for several seconds). Filtering on === 'BEHIND' silently dropped genuine candidates whose state had not yet settled — observed in run 25248773692 where an auto-merge PR was BEHIND but the run logged "No auto-merge PRs need updating". Drop the BEHIND filter; iterate eligible auto-merge PRs from oldest and let updateBranch's response decide whether work was done. On failure, warn and continue to the next.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4678 +/- ##
============================================
- Coverage 46.15% 46.15% -0.01%
Complexity 1993 1993
============================================
Files 1013 1013
Lines 38165 38165
Branches 3712 3712
============================================
- Hits 17616 17615 -1
Misses 19774 19774
- Partials 775 776 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
- Retry the scan-and-update cycle up to 6 times with backoffs summing to ~120s. mergeable / mergeStateStatus are computed asynchronously and can be UNKNOWN right after a base-branch push, so a single early scan misses real candidates. - Add 'schedule: 0 * * * *' so PRs that become BEHIND between merges (force-push to base, late auto-merge enable) still get advanced. - Log every scanned PR with its verdict (skip reason or eligibility + current state), every updateBranch attempt with HTTP status, and per-attempt summary so the run history is enough to debug from.
…lity Only update PRs that would actually merge once CI passes: add reviewDecision === 'APPROVED' and zero unresolved review threads to the eligibility check. Skips with a specific log line so it's clear why a PR was passed over. Avoids burning CI on PRs blocked on review.
aglinxinyuan
approved these changes
May 2, 2026
added 2 commits
May 2, 2026 02:48
Reinstate the BEHIND filter: only act on PRs whose head is genuinely out of date with main. Don't waste a write on a PR that's already CLEAN or otherwise blocked. Backoff retries are now narrowly scoped: continue only while at least one eligible PR is UNKNOWN (i.e., GitHub is still recomputing state after a base-branch push). If all eligible PRs have settled and none are BEHIND, exit immediately rather than burning the full ~2min budget.
Yicong-Huang
changed the title
Yicong-Huang
added a commit
that referenced
this pull request
May 3, 2026
…ight (#4845) ### What changes were proposed in this PR? Two changes to `.github/workflows/auto-queue.yml`. **1. More triggers, shorter cron.** Add `pull_request {auto_merge_enabled, ready_for_review}`, `pull_request_review {submitted}`, `workflow_run {Required Checks completed}`, and drop cron from hourly to every 5 min. Each event covers a state change that previously waited up to an hour for cron — most notably `workflow_run completed` lets us bump the next PR the moment the head PR's CI finishes (pass or fail). **2. In-flight guard.** GraphQL now pulls `statusCheckRollup.state`. If any eligible PR has `mergeStateStatus != BEHIND` and CI is `PENDING / EXPECTED / SUCCESS`, the run exits without bumping anyone — the queue head is already moving, and preempting CI on another PR would just force a re-bump after the head merges. `BEHIND + PENDING` does not count (CI runs on pre-update code), and `BLOCKED + FAILURE/ERROR` does not count (won't auto-merge, release the guard). ### Any related issues, documentation, discussions? Tracking issue: #4553. Builds on #4672 (initial workflow) and #4678 (UNKNOWN retry + eligibility gates). ### How was this PR tested? Workflow YAML parses clean. Decision logic is exercised by every trigger after merge — no separate test harness for this workflow today. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Opus 4.7, 1M context) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Yicong-Huang
added a commit
that referenced
this pull request
May 3, 2026
### What changes were proposed in this PR? Add an `emergency` label fast-path to Auto Queue. A PR with this label is bumped before any non-emergency PR regardless of CREATED_AT, and its presence in BEHIND bypasses the in-flight guard so a non-emergency PR's running CI doesn't delay the bump. Within each priority class CREATED_AT-ASC ordering is preserved. Eligibility gates (auto-merge / not draft / not conflicting / APPROVED / threads resolved) still apply — this only reorders the bump, it does not bypass review. Label name is set by the `EMERGENCY_LABEL` constant (one-line change if `priority/P0` or similar is preferred later). ### Any related issues, documentation, discussions? Builds on #4672, #4678, #4845. ### How was this PR tested? `yaml.safe_load` parses; `node --check` parses the wrapped script body. Unit test on the partition logic: `[#100 docs, #101 emergency, #102 plain, #103 emergency+fix]` → `[101, 103, 100, 102]`. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Opus 4.7, 1M context) Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
What changes were proposed in this PR?
Iterates on
.github/workflows/auto-queue.ymlso it actually picks up the candidate PR after a push to main:UNKNOWN: query → categorize eligible PRs intoBEHIND/UNKNOWN. If any areUNKNOWN, sleep and retry up to ~120s (delays0/10/20/30/30/30s); GitHub recomputesmergeStateStatusasynchronously after a base-branch push, so the first scan often seesUNKNOWNfor everything. Stop retrying as soon as aBEHINDPR is updated, or as soon as nothing isUNKNOWNand nothing isBEHIND(don't waste the 2-min budget).schedule: 0 * * * *): catches PRs that goBEHINDbetween merges (force-push to base, late auto-merge enable, etc.).reviewDecision === 'APPROVED'and zero unresolved review threads. Avoids burning CI on PRs that wouldn't merge even with a green build.skip: <reason>oreligible: mergeable=… state=…), per-attempt grouped output, everyupdateBranchcall with HTTP status, retry/backoff announcements, final summary with elapsed seconds. Each attempt is wrapped incore.startGroupso the Actions UI collapses them.AutoQueue→Auto Queue.Eligibility, in plain terms
A PR is acted on only if all of the following hold:
reviewDecision === 'APPROVED'.mergeStateStatus === 'BEHIND'(UNKNOWN triggers retry; CLEAN/BLOCKED/etc. are no-ops).Any related issues, documentation, discussions?
Follow-up to #4672. Same
AUTO_MERGE_TOKENPAT contract.Originally observed in run 25248773692: the workflow fired ~3s after a push to main, when GitHub had not yet recomputed
mergeStateStatus. PR #4652 was a real candidate but came back asUNKNOWN, so the strict filter dropped it and the run logged "No auto-merge PRs need updating". The retry loop here is the targeted fix.How was this PR tested?
Workflow runs only on push-to-main, schedule, and
workflow_dispatch. Will observe behavior on the next merge and on the next scheduled run after this lands.Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Opus 4.7 (Claude Code)