agent rebased an approved upgrade PR and the rebase pulled a breaking change from main that invalidated the approval
Fixes rebases that silently pull breaking changes from main into an already-approved upgrade PR, invalidating the approval. Use when a rebased PR was merged on a stale approval. Key trigger: the merge commit contains upstream changes that were never reviewed.
TL;DR: Treat any rebase after approval as invalidating the approval: re-run the full CI suite and re-request review on the new commits. The rebase folded main's breaking change into the "approved" branch, so the approval no longer describes the code being merged. Enable dismiss-stale-reviews in branch protection so this is enforced structurally, not remembered.
agent rebased an approved upgrade PR and the rebase pulled a breaking change from main that invalidated the approval- Identify what the rebase pulled in: compare the rebased branch's log against the approved commit. Expected: new upstream commits from main that were not part of the approved version.
- Find the break: run the full test suite on the rebased branch. Expected: failures trace to the main-side change interacting with the bump.
- Fix the interaction - update the bump, pin, or adapt to the breaking change. Expected: the full suite is green on the rebased branch.
- Re-request review, explicitly noting the rebase and what changed since the approval. Expected: a fresh approval on the actual merge commit.
- Enforce it structurally: turn on "dismiss stale pull request approvals when new commits are pushed" in branch protection. Expected: any push after approval auto-dismisses it, so the agent cannot merge on a stale approval again.
Use this when
- A rebased PR was merged on an old approval
- A rebase pulled breaking changes in from main
- You need approval-invalidation policy for rebases
- The merge commit differs from the approved commit
Not for this skill when
- The rebase brought in no new upstream commits (fast-forward only)
- CI re-ran and passed post-rebase and review was re-requested - then it is just process
- Conflicts were resolved by hand with no upstream changes involved
Variant phrasings
- Rebase invalidated PR approval
- Approved PR rebased with breaking change from main
- Stale approval after rebase
- Merged on an approval that no longer matches the code
Why it happens
Approvals attach to a commit SHA, but agents (and humans) treat them as attaching to the PR. A rebase rewrites every commit, so the approved SHA no longer exists in the branch - yet the "approved" label survives in the agent's mental model. Meanwhile main kept moving, and the rebase folded a breaking change into the branch under cover of the old approval.
Edge cases
- Merge queues rebase again at merge time - the final SHA needs its own CI run, not the pre-queue one
- Dismiss-stale-reviews can annoy on doc-only pushes - scope the rule to upgrade paths if needed
- If the breaking change is in main itself, the fix belongs on main, not inside the upgrade PR
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_icX7eTyTvARPDBhBFOEl7A