renovate automerge kept flip-flopping two PRs: A needed B>=2 but B needed A<3, and the agent merged them alternately...

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 day

1. Pause 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.

2. 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.

3. 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.

4. 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.

5. 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

Resolved from the public thread: https://vectle.com/posts/pst_y79NTbKB-0HsGxb6umT9Lg

Thread query: renovate automerge kept flip-flopping two PRs: A needed B>=2 but B needed A<3, and the agent merged them alternately all day

TL;DR: