When Does a Pull Request Need Another Review?
A reply, a focused fix and rewritten history need different follow-up. Check what happened after your pull request review before opening the full diff again.
One colleague pings me on Slack every time a pull request is ready for another look. The last ping came as soon as it was ready.
What was waiting has varied. Once, the author had pushed the fix I asked for. On another pull request there was no fix to inspect. The author had replied to my comment, and after reading it I realised the issue I raised was not an issue.
Find the first event after your review
The first useful detail is the event immediately after the review. Here are four cases that lead to different work:
| What happened | Start here | Likely scope |
|---|---|---|
| The author replied without changing code | The original conversation | Decide whether the concern still holds and whether you owe a reply |
| The author pushed a focused fix | The original conversation and the new commit | Check the requested change and the code immediately around it |
| Several commits landed | Changes since your last review | Match the new work to open comments, then follow any changed assumptions |
| The branch was rebased or rewritten | The affected files and current history | Work out which parts of the earlier review you can still trust |
Several new commits can turn out to be one contained fix. A short reply can expose an assumption that affects the rest of the review. You have to open the handoff before you know.
Sometimes the work is one reply
There was no diff to check in that second pull request. My comment was the part that needed another look. I was wrong about that one.
The author's answer supplied context I had missed. In a case like that, I'd read the answer against the original comment. If it holds, I can close the thread or acknowledge it. If something is still unresolved, I can ask about that smaller point.
Going straight to the code would have put me in the wrong place. The useful information was already under my comment.
A later reply still needs reading if you approved the pull request earlier or the code around the thread has moved. The age of the thread says nothing about when the last person spoke.
New code needs a review boundary
When the author pushed a fix, mark the version you had already seen. Then decide how far beyond the new commit to read.
A narrow fix usually starts with four checks:
- Does the change answer the original comment?
- Did it alter a neighboring assumption or caller?
- Did the relevant tests change with it?
- Did unrelated work arrive in the same update?
If those checks stay local, the delta may be enough. Widen the pass when a new abstraction replaced the one you reviewed, conflict resolution rewrote nearby code, or unrelated edits arrived in the same update. After a larger rewrite, I would use the old review as notes and check the affected area again.
The longer guide on re-reviewing without starting over goes deeper on choosing between a commit-level delta and a fresh pass.
There are also review requests where I would struggle to find anything new.
Maybe the reviewer was requested again before the next push. Maybe the branch now conflicts with its base. Opening every file again will not move either case forward.
I'd look for the reply, commit, or branch change that made the request actionable. If I cannot find one, the useful response is one concrete question to the author: what is ready for another look?
Authors can make that handoff cheaper by replying on the relevant thread and keeping the requested fix separate from unrelated cleanup. That also leaves something useful for a second reviewer who never saw the Slack message.
Put the return in the active queue
In r/programming discussions about re-review, people describe new commits or a rebase arriving without the reviewer noticing. When they eventually return, they have to work out which parts they already inspected.
PR Flow puts author replies and new review work back in Needs you. The review queue and PR Flow's GitHub pull request dashboard separate those items from work still waiting on someone else.
For a reply-only return, the Reply marker leads back to the conversation. When new commits are the reason for the re-review, opening it starts with the commits since your last reviewed point. I would still read the originating conversation before deciding whether that delta answers it. Show all remains beside the diff. If the earlier commit disappeared after the branch was rewritten, PR Flow shows the full change.
I still have to decide whether the explanation settles my comment. I still have to check whether a focused fix changed something nearby, and whether the current history deserves a full pass.
The earlier guide to who owns the next move covers these handoffs in more detail. A pull request can leave the reviewer's queue after feedback, then return with a reply or new code.
I am less sure what a team should do with authors who always add a Slack ping. It makes the handoff obvious, and it also creates a second system that only works while somebody keeps using it.