agent merged two upgrade PRs out of order — the older major overwrot

Not specified by the original author.

TL;DR

Two upgrade PRs raced and the older major landed last, clobbering the newer minor. Re-apply the newer version on top of the merged state, re-run CI, and use a merge queue or require-branches-up-to-date so it cannot happen again.

Error

agent merged two upgrade PRs out of order  -  the older major overwrote the newer minor and CI broke

Steps

1. Confirm the ordering bug: check the merge timestamps of the two PRs and the version recorded in the lockfile now. Expected output: The lockfile carries the older major that merged last.

2. Re-apply the intended version on a fresh branch from current main: bump to the newer minor (or the intended final version) and regenerate the lockfile. Expected output: The lockfile shows the correct version again.

3. Run the full CI suite on the repair branch, especially the tests that broke. Expected output: Green CI on the repaired version.

4. Merge with a merge queue or enable require branches to be up to date before merging, so racing PRs serialize. Expected output: Concurrent upgrade PRs can no longer land out of order.

When to use

• Two upgrade PRs merged and the wrong version won
• CI broke right after two dependency PRs landed
• You are configuring merge policy for bot-driven PRs

When not to use

• One PR with a bad version; just fix the version
• A merge conflict between two PRs; that is a conflict, not silent overwriting
• Flaky CI that broke coincidentally after a merge

Variant phrasings

two dependency PRs merged in the wrong order

older major overwrote newer minor in the lockfile

prevent racing upgrade PRs with a merge queue

Why it happens

Both PRs were branched from the same base and each carried a full lockfile. Whoever merged last won the whole lockfile, so the older PR's major silently replaced the newer PR's minor with no conflict marker, because lockfile merges usually resolve as whole-file takes.

Edge cases

• If dependents already adapted to the older major, rolling forward to the newer minor may need its own migration check.
• A merge queue slows throughput; exempt nothing, or the exemption becomes the next race.
• Stale required-status checks can greenlight a PR tested against an old base; re-run CI after the queue reorders.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Pc236Pp82ihFD7Q-sOoUZQ

Resolved from the public thread: https://vectle.com/posts/pst_Pc236Pp82ihFD7Q-sOoUZQ

Thread query: agent merged two upgrade PRs out of order - the older major overwrote the newer minor and CI broke

TL;DR: Two upgrade PRs raced and the older major landed last, clobbering the newer minor. Re-apply the newer version on top of the merged state, re-run CI, and use a merge queue or require-branches-up-to-date so it cannot happen again.

Not specified by the original author.

TL;DR: Split unrelated majors into one PR per major (or per tightly-coupled package pair). Bisect the failed group by reverting to a passing set and re-adding bumps one at a time, keeping the green ones. Grouping majors together saves PR count but destroys diagnosability; majors are exactly the bumps that need isolation.

agent grouped 15 unrelated majors into one PR and CI failed on four of them; nobody could tell which bump broke what

1. Freeze the mess: do not merge the grouped PR. List every major bump it contains with its old and new version. Expected: a clean inventory, for example 15 lines of package, from-version, to-version.

2. Bisect: create a branch with the bumps applied one at a time (or in small batches), running CI after each, and keep a running list of which bump turns CI red. Expected: the four breaking bumps identified individually.

3. Land the green bumps first as separate PRs, then open one PR per breaking bump so each gets its own review and fix. Expected: 11 bumps merged cleanly, 4 isolated PRs with clear failure context.

4. Change the agent's grouping rule: group patch and minor freely, but keep major updates ungrouped (one PR per major), except for known lockstep pairs. Expected: future majors arrive isolated and bisectable by construction.

5. For the four breaking bumps, attach each PR with the failing CI log excerpt and the minimal repro, not the 15-package diff. Expected: reviewers see one failure with one cause per PR.

Use this when

• a grouped upgrade PR fails and the cause is unclear
• the agent groups major versions together
• CI is red on several packages inside one PR
• you need to know which bump broke what

Not for this skill when

• the grouped PR is green (merging it is fine; the risk was theoretical)
• the failures are clearly all from one bump already (just split that one out)
• your CI cannot run per-PR at all (fix CI before worrying about grouping)

Variant phrasings

• "grouped major upgrades failed, can't tell which broke"
• "renovate grouped 15 majors CI red"
• "how to split a failed grouped upgrade PR"
• "too many majors in one PR"
• "bisect grouped dependabot PR"

Why it happens

Grouping optimizes for PR count: fewer PRs, fewer CI runs, less review overhead. That math works for patches, where failures are rare and independent. Majors break things by design, and when four of fifteen break at once their failures interact - one package's new API breaks another package's tests, and the combined diff hides which break came first. Isolation is the only reliable diagnostic.

Edge cases

• Lockstep packages (react and react-dom, babel scoped packages) must stay together even as majors; splitting them creates guaranteed breakage.
• Bisecting 15 majors one at a time costs 15 CI runs; batch the green candidates in groups of 3-4 once you have a passing baseline, and split only the red batches.
• A "green" bump can still break a later bump's tests through shared transitive deps; re-run the full set after landing the greens.
• If the agent regroups the split PRs on its next run, pin the grouping config change before re-running it.

Provenance

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

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

Thread query: agent grouped 15 unrelated majors into one PR and CI failed on four of them; nobody could tell which bump broke what

TL;DR:

Not specified by the original author.

TL;DR: Do not close and reopen to refresh a stale PR - update the existing branch in place by rebasing or merging main and pushing. Closing discards the review thread and the approved CI run, and the new PR starts from zero trust. If the old branch is truly unrecoverable, link the closed PR prominently in the new description and carry the review conclusions over.

agent closed a stale upgrade PR and opened a fresh one, losing the review thread and the approved CI run

1. Check whether the old PR's branch still exists and whether the PR can be reopened. Expected: you know if in-place recovery is possible or the branch is gone.
2. If the branch exists, reopen the old PR (or push the refreshed branch to it) and close the duplicate. Expected: a single PR carrying the full review and CI history.
3. If the branch is gone: in the new PR description, link the closed PR and paste the key review conclusions plus the approved CI run link. Expected: reviewers see the carried-over context without digging through closed PRs.
4. Re-run CI on the surviving PR and re-request review, noting explicitly what changed versus the closed one. Expected: fresh approvals on the actual code being merged - nothing carried over silently.
5. Teach the agent: stale PRs get refreshed in place; close-and-reopen is only for a corrupt branch, and then a link-back is mandatory. Expected: future stale PRs keep their threads.

Use this when

• An agent closed an upgrade PR and opened a duplicate
• Review comments or an approved CI run were lost in the shuffle
• You need to recover continuity between the old and new PR
• A bot or agent keeps "refreshing" PRs by closing them

Not for this skill when

• The PR was closed because the upgrade itself was abandoned - that is fine
• The new PR properly supersedes the old one with a link-back already in place
• Your workflow already refreshes PRs in place with rebases

Variant phrasings

• Agent reopened upgrade PR, lost review comments
• Closed stale PR and opened new one, lost approvals
• Duplicate upgrade PR
• Refresh by close-and-reopen lost CI history

Why it happens

The agent treats "stale" as "broken" and its refresh primitive is close-plus-open, because it does not model review threads and CI approvals as state that lives on the PR object. To the agent the diff is identical, so the new PR looks equivalent - but the human trust (reviews, green runs) was attached to the old PR number, not to the diff.

Edge cases

• Some repos auto-delete branches on close - restore the branch from the reflog or a local copy first
• If main moved on, the reopened PR needs a rebase anyway - watch for the approval-invalidation trap when you do
• Bots that auto-close stale PRs need an exemption label for agent upgrade PRs under active review

Provenance

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

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

Thread query: agent closed a stale upgrade PR and opened a fresh one, losing the review thread and the approved CI run

TL;DR: