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

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: Security updates always ship in their own PR, separate from every other bump. Split the security patch out of the grouped PR, merge and release it first, then deal with the major on its own timeline. Configure the agent to treat security-flagged updates as their own group with priority handling. A CVE fix must never wait on unrelated breakage.

agent grouped a security patch with a major upgrade; the security fix couldn't ship until the major's breakage was fixed

1. Identify the security-flagged update inside the grouped PR (advisory ID, CVE number, or the scanner's severity label). Expected: one clearly-labeled security bump among the grouped changes.

2. Cherry-pick just the security bump onto a fresh branch and open it as its own PR with the advisory reference in the body. Expected: a minimal PR containing only the security fix.

3. Run CI on the security PR alone and merge it as soon as it is green, on the normal release train or hotfix path. Expected: the CVE fix ships while the major is still being fixed.

4. Leave the major upgrade in its own PR to be fixed and reviewed on its own timeline. Expected: the major's breakage no longer blocks anything security-related.

5. Change the agent's grouping config so security-flagged updates always form their own group, separated from feature and major bumps, with automerge-on-green if your policy allows it. Expected: the next advisory arrives as a standalone PR by default.

Use this when

• a CVE fix is bundled with an unrelated major upgrade
• a security patch is blocked by someone else's breakage
• the agent groups all updates into one PR regardless of severity
• auditors ask why a known CVE sat unpatched for weeks

Not for this skill when

• the security fix itself requires the major upgrade (then they are genuinely coupled; document why)
• the "security" label is a false positive from the scanner (downgrade the severity first)
• your policy forbids automerge on security PRs (keep the separate PR, just review it manually)

Variant phrasings

• "security patch stuck behind major upgrade"
• "CVE fix blocked by grouped PR"
• "renovate grouped security update with major"
• "how to separate security updates from regular bumps"
• "dependabot security PR mixed with feature upgrades"

Why it happens

Grouping rules usually key on schedule or package, not severity, so a security patch lands in whatever group was forming that day. The agent sees one fewer PR as a win. But security fixes and major upgrades have opposite risk profiles: the patch must ship fast with minimal change, the major needs slow careful review. Bundling them forces the fast item to move at the slow item's pace, which is exactly backwards.

Edge cases

• Some advisories only publish a fix on the new major line; then the security PR legitimately includes a major. Say so in the PR body so reviewers know it is not optional.
• Backport branches may need the same security patch separately; check whether the advisory affects maintained older lines.
• Automerging security PRs can still break the build; keep the CI gate, just skip the human review queue when policy allows.
• If the scanner flags a devDependency CVE as critical, weigh exploitability before hotfixing; not every critical needs the fast lane.

Provenance

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

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

Thread query: agent grouped a security patch with a major upgrade; the security fix couldn't ship until the major's breakage was fixed

TL;DR: