renovate automerge kept flip-flopping two PRs: A needed B>=2 but B needed A<3, and the agent merged them alternately...
Fixes Renovate automerge flip-flopping between two PRs whose version ranges constrain each other. Use when an upgrade agent merges two dependency PRs back and forth all day because A needs B 2.0 or newer while B needs A older than 3. Key trigger: two Renovate PRs alternately undoing each other.
TL;DR: Stop automerging the two packages and put them in one Renovate group so they land as a single PR. The pair can never settle independently because A's range requires B 2.0 or newer while B's range requires A older than 3, so alternating merges are the only possible outcome. Find one pair of versions that satisfies both constraints, merge it once by hand, then re-enable automerge on the group.
A needed B>=2 but B needed A<3, and the agent merged them alternately all dayPause automerge for both packages. Add a packageRule matching the two packages with automerge turned off, or apply a manual-approval label the bot respects. Expected: no new automerge runs pick up either package; the flipping stops immediately.
Put both packages in one Renovate group (same groupName in the packageRule) so the bot opens a single PR instead of two competing ones. Expected: one PR appears touching both A and B, replacing the two flip-flopping PRs.
Resolve a compatible pair by hand: pick a version of A older than 3 and a version of B at 2.0 or newer such that each satisfies the other's peer range. Read both packages' peerDependencies to confirm. Expected: one concrete version pair that satisfies both ranges at once.
Push the pinned pair on the grouped branch and merge it manually with CI green. Expected: CI passes, the flip-flop stops, and no new PRs appear for either package.
Re-enable automerge only after confirming both packages' constraints stay satisfiable, and keep them grouped going forward. Expected: future bumps arrive as one grouped PR that can actually merge.
Use this when
- Renovate automerge merges two PRs back and forth, each undoing the other
- Two dependencies constrain each other's version ranges (A needs B newer, B needs A older)
- The agent "merged them alternately all day" with no progress
- Peer ranges that cannot both float independently
Not for this skill when
- Dependabot PRs are flipping (different tool, different grouping model)
- npm fails at install time with an ERESOLVE peer conflict (install-time resolution, not PR scheduling)
- A single upgrade PR fails CI for an unrelated reason
- Lockfile churn with no version-range coupling between the packages
Variant phrasings
- renovate merged A then B then A again, undoing itself each time
- two renovate PRs undoing each other in a loop
- automerge loop between interdependent packages
- peer range conflict spread across two renovate PRs
Why it happens
Automerge treats each PR as independent, but the version constraints couple them: merging A's bump invalidates B's range and merging B's bump invalidates A's. Without a group, the scheduler has no way to see the pair as one decision, so it just keeps alternating. This is a planning problem, not a test problem: no amount of green CI fixes mutually exclusive ranges merged separately.
Edge cases
- If no version pair satisfies both ranges, the dependencies are genuinely incompatible: one must be replaced or a range widened upstream. Grouping cannot fix that.
- Keep the group to exactly the coupled packages; grouping unrelated majors recreates the "which bump broke CI" problem.
- Check the grouped branch name is stable so CI caches survive across the bot's rebases.
- If other open PRs depend on either package, sequence them after the grouped merge lands.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_y79NTbKB-0HsGxb6umT9Lg