changes requested must be addressed before merging" error

TL;DR

Address the feedback, push the fixes, and get the reviewer to re-review - only a new approving review (or a dismissal by someone with permission) clears the block. Replying in comments alone doesn't clear it, and pushing code doesn't auto-clear it either.

The error

"changes requested must be addressed before merging" error

Steps to fix

1. Read the requesting reviewer's comments and make the code changes they asked for.

• Expected: every piece of feedback has a corresponding change or a written reason it doesn't apply.

1. Push the fixes to the PR branch.

• Expected: the PR timeline shows the new commits.

1. Re-request the reviewer's review (or ask them to take another look) so they can approve the new head.

• Expected: the reviewer is notified; nothing auto-notifies them that you pushed.

1. Wait for their approving review.

• Expected: the block clears when the approval lands; a dismissal by someone with permission clears it too.

Use this when

• The merge box says changes were requested and must be addressed.
• A reviewer left a "request changes" review and the PR is otherwise ready.
• You pushed fixes but the block is still there (the re-review hasn't happened).

Not for this skill when

• The blocker is missing reviews rather than requested changes (get a first review instead).
• The blocker is a failing check (fix the check).
• The team norm is that anyone's approval unblocks (check branch protection - "request changes" is still a veto there by default).

Variant phrasings

• changes requested must be addressed before merging
• PR blocked changes requested github
• how to clear request changes review
• requested changes blocking merge

Why it happens

A "request changes" review is a persistent veto in branch protection: it stays blocking until that reviewer (or someone with dismiss permission) resolves it. Pushing code doesn't auto-clear it because GitHub can't tell whether the push addressed the feedback - only the reviewer can judge that, so the veto waits for their verdict.

Edge cases

• The reviewer is unavailable: someone with dismiss-review permission can dismiss the stale request.
• Stale-dismissal settings may auto-dismiss the request on push - then you just need any fresh approval.
• Multiple reviewers requested changes: each requester must resolve; one approval doesn't override another's veto.
• If you disagree with the feedback, say so in the thread and ask for dismissal rather than pushing changes you don't believe in.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fjbBTaasyJGj0KQ2Iv9E6Q