fix(review-checklist): re-request dismissed reviewer on fixup push#6479
Merged
brtnfld merged 5 commits intoJun 23, 2026
Merged
Conversation
When a new commit dismisses a prior reviewer's approval, GitHub's CODEOWNERS engine auto-assigns a fresh (possibly different) owner for the changed area. The synchronize handler now detects dismissed area-owners and swaps them back in, removing the fresh CODEOWNERS pick. Adds planSynchronizeSwaps() pure helper (exported) with 7 unit tests covering the PR 6475 scenario and edge cases.
brtnfld
requested review from
glennsong09,
hyoklee,
jhendersonHDF and
lrknox
as code owners
Contributor
Review ChecklistThis PR touches the following areas. Each needs a sign-off
|
…her area planSynchronizeSwaps could remove a fresh CODEOWNERS pick to restore a dismissed reviewer even when that pick also covered a different, unrelated touched area — removeRequestedReviewers strips them from the whole PR, silently uncovering the other area. Now skips removal when the candidate owns any other touched area. Also dedupes the consuming loop so a login needed by two areas isn't requested/removed twice. 5 new tests covering the cross-area guard and its boundaries.
…sticky exclusion The bot's own removeUnselected/removeRequestedReviewers calls (draft-opened CODEOWNERS cleanup, stale-exclusion enforcement) fire review_request_removed, which the workflow also listens on — self-triggering another run. That run previously read its own bookkeeping removal as a deliberate human decision and added the login to the persisted exclusion set, permanently blocking that owner from ever being auto-assigned to the PR again. Guard on sender.type !== 'Bot' so only human-driven removals become sticky.
… event wins the race GitHub's CODEOWNERS engine fires one review_requested event per auto-assigned owner on PR creation, and each re-triggers this workflow. With concurrency: cancel-in-progress, whichever run starts last wins — and that's just as likely to be one of those review_requested runs as the opened run itself. A surviving review_requested run fell through to the additive-fill branch, saw every area already "covered" by the avalanche, and pruned nothing. This hit PR HDFGroup#6479 itself: all 4 CODEOWNERS for .github/ stayed requested. Branch on whether a checklist comment exists yet instead of which action survived — that signal is race-resistant: no comment means this is the PR's first coordination pass no matter which event got here. Threads hasExistingComment through from run() (defaulting to true, i.e. additive-fill, on a comment-fetch failure so an API hiccup can't be mistaken for a fresh PR). 2 new tests: the HDFGroup#6479 race itself, and a contrast case confirming a routine review_requested on an already-established PR still uses additive-fill.
hyoklee
approved these changes
Jun 22, 2026
github-project-automation
Bot
moved this from To be triaged
to Done
in HDF5 - TRIAGE & TRACK
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
2 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.
Summary
When a PR author pushes a fixup commit, GitHub dismisses existing approvals and its CODEOWNERS engine auto-assigns a fresh (possibly different) owner for the changed area. The
synchronizeevent handler previously treated the fresh CODEOWNERS pick as the authoritative assignment and did nothing — leaving the dismissed reviewer (who already has context) off the PR.planSynchronizeSwaps()— a pure helper that identifies dismissed area-owners who should be re-requested and the fresh CODEOWNERS pick to remove in their placesynchronize, the handler now removes the fresh pick and re-requests the dismissed reviewerreview_request_removed) are never re-requested