Repository navigation
fix: PR hygiene runs every event to the end and lets the newest payload decide (#526) - #528
Merged
Merged
Conversation
…ad decide (#526) The concurrency group cancelled every run still going when the next event arrived, and GitHub counts a cancelled run in the commit's status: 61 of the last 100 merged PRs showed FAILURE for nothing but cancelled hygiene runs. The group is gone, so no run is cancelled. Each run waits 20 s for a burst of events to settle, then compares its payload's head, base, labels and description with the PR as it is now. If any changed, the event that changed it started a newer run, so this one passes without checking. Measured on the throwaway PR #527; the numbers are in the workflow's header. Found-By: IS Defect-Class: PKG Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
CaffeinatedCoder
added
bug
This was referenced Oct 29, 2026
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
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.
Closes #526
Problem
pr-hygiene.ymlhadconcurrency: { group: pr-hygiene-<number>, cancel-in-progress: true }. A PR pushed and then labelled and described within seconds starts one run per event, and the group cancelled every run still going when the next one started. GitHub counts each run in the commit's status, and a cancelled run counts as failing. So 61 of the last 100 merged PRs show a red status for nothing but cancelled hygiene runs, with every other check green. For example, #520 has three cancelled runs and one green one.Dropping the group alone doesn't fix it. Measured on #527: five events in seven seconds all ran to the end, but the two whose payloads failed (no labels yet; two type labels at once) left the status FAILURE beside a green latest run.
Change
.github/workflows/pr-hygiene.yml:gh apiwith the read-onlyGITHUB_TOKEN, sopull-requests: read). If any of them changed, the event that changed it started a newer run, which decides, and this run passes without checking. Only those four fields are compared, because a change to any of them is itself a trigger (synchronize,edited,labeled,unlabeled). A milestone or assignee change can't make the newest run skip itself.pr-hygiene.shrun only when the payload is current. The script is unchanged and still needs no token.No changelog row: CI only, like #410.
Tests
On the throwaway PR #527 (CI workflows removed on that branch; a payload without labels held back 60 s so it finishes last):
The last row is the fail-closed check. If the payload and the API spelled a field differently, every run would pass as superseded. Here the newest run compared equal and judged.
A run that judged a payload the PR really had (labels missing at that moment) still stays red after the labels are fixed, as before. Only a re-run clears it.
Once this merges, it gets cherry-picked with
-xintorelease/10.x, because the workflow runs from the PR's base.🤖 Generated with Claude Code