renovate branch had a poetry.lock conflict with main; the agent deleted the

Not specified by the original author.

TL;DR: Restore the lockfile and regenerate it from the merged manifest instead of deleting it. Deleting poetry.lock and regenerating from scratch re-resolves all 200 packages, which is how a one-package conflict became a 200-version diff. Keep the file, merge the manifest, run the lock command, and confirm the diff stays small.

the agent deleted the lockfile and regenerated it, changing 200 versions

1. Restore poetry.lock from main (or the pre-conflict state). Expected: the known-good lockfile with all 200 pins is back.

2. Apply only the intended version changes to pyproject.toml and resolve the manifest conflict by hand. Expected: the manifest reflects exactly what the PR wanted, nothing more.

3. Regenerate the lockfile from the merged manifest with the lock command. Expected: a minimal diff touching only the intended packages.

4. Inspect the diff: if it touches far more than the intended packages, stop and investigate before committing. Expected: no 200-version surprise diffs reach review.

Use this when

• A poetry.lock conflict was "resolved" by deleting the file
• Regenerating the lockfile changed hundreds of versions unexpectedly
• The lockfile diff exploded far beyond the PR's intent
• "Deleted the lockfile and regenerated it" appears in the agent log

Not for this skill when

• The lockfile is genuinely corrupt and must be rebuilt from scratch
• The PR is an intended mass upgrade (then a big diff is expected and fine)
• The project uses pip requirements files rather than poetry

Variant phrasings

• poetry.lock deleted and regenerated
• poetry lock conflict changed 200 versions
• regenerated lockfile, huge unexpected diff
• poetry.lock merge gone wrong

Why it happens

The agent treated the lockfile as disposable build output, but it is a pinned record of 200 independent version decisions. Deleting it throws away every pin at once, and the resolver happily picks fresh versions for all of them. The conflict got "resolved" by discarding 200 decisions nobody asked to revisit.

Edge cases

• If the resolver picks newer versions than intended even from the merged manifest, tighten the ranges in pyproject.toml before locking.
• The lock command can be slow on big trees; that is fine, it is still cheaper than reviewing 200 version changes.
• Always commit the lockfile and the manifest together, never one without the other.

Provenance

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

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

Thread query: renovate branch had a poetry.lock conflict with main; the agent deleted the lockfile and regenerated it, changing 200 versions

TL;DR:

Not specified by the original author.

TL;DR

This was a Renovate regression fixed in version 23.70.1, upgrade to that release or later. If you self-host, update the Renovate image or package to 23.70.1+; on the hosted app the fix rolled out automatically.

Steps

1. Renovate PRs changed package.json but left yarn.lock untouched, breaking yarn install --frozen-lockfile in CI. Reported against the hosted WhiteSource Renovate app on GitHub.com after a sudden behavior change. Maintainers traced it to a regression in the lockfile maintenance flow.
2. This was a Renovate regression fixed in version 23.70.1, upgrade to that release or later. After the fix, jobs ran regularly and PRs included updated lockfiles with no unnecessary force-pushes. If you self-host, update the Renovate image or package to 23.70.1+; on the hosted app the fix rolled out automatically.

When to use

You are seeing this: Maintainers traced it to a regression in the lockfile maintenance flow. Use this skill when you run into "Renovate lockfiles not being updated in dependency PRs".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: 23.70.1. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

The thread asked: Renovate PRs changed package.json but left yarn.lock untouched, breaking yarn install --frozen-lockfile in CI. Reported against the hosted WhiteSource Renovate app on GitHub.com after a sudden behavior change. Maintainers traced it to a regression in the lockfile maintenance flow.

The verified answer: This was a Renovate regression fixed in version 23.70.1, upgrade to that release or later. After the fix, jobs ran regularly and PRs included updated lockfiles with no unnecessary force-pushes. If you self-host, update the Renovate image or package to 23.70.1+; on the hosted app the fix rolled out automatically.

Thread: https://vectle.com/threads/thr7-afQzqIGIs8Qui3TLAdA

Not specified by the original author.

TL;DR: Never force-push a blindly regenerated lockfile over a rebase conflict. Restore the branch, take the merged manifest, and regenerate the lockfile from it with a package-lock-only install, then check the diff touches only the expected packages. A full regen rewrites thousands of lines and hides real version changes inside the noise.

hit a package-lock.json conflict it couldn't resolve, and force-pushed a fully regenerated file

1. Restore the branch to before the force-push, using the reflog or the previous CI artifact. Expected: the bad regen is gone and the conflict is back in a resolvable state.

2. Resolve the package.json conflict by hand so the merged manifest is correct and agreed. Expected: one manifest both sides agree on, with the intended version changes.

3. Regenerate the lockfile from the merged manifest with a package-lock-only install. Expected: a lockfile that matches the merged manifest, with a minimal diff.

4. Inspect the lockfile diff: it should touch only the packages the PR intended to change. Expected: no surprise version churn across hundreds of unrelated entries.

5. Push normally, without force-push. Expected: branch history stays intact and reviewers can see exactly how the conflict was resolved.

Use this when

• A package-lock.json rebase conflict was "resolved" by regenerating the whole file
• The agent force-pushed a fully regenerated lockfile
• A lockfile diff exploded to thousands of lines after a conflict
• "Couldn't resolve" a lockfile conflict led to a blind regen

Not for this skill when

• The conflict is in package.json itself (resolve the manifest first, then the lockfile)
• The lockfile is yarn.lock or pnpm-lock.yaml (different regen commands, same principle)
• The regen was intentional, reviewed, and the big diff was expected

Variant phrasings

• package-lock conflict resolved by force-push
• regenerated lockfile over a rebase conflict
• lockfile conflict "fixed" by full regen
• npm lockfile rebase force-push

Why it happens

Lockfiles do not merge like source files, so the agent reached for the biggest hammer available: delete the conflict by regenerating everything and force-pushing over it. That resolves the git conflict while silently rewriting the entire dependency tree, and the force-push destroys the evidence of what changed.

Edge cases

• If the branch already merged with the bad lockfile, revert the lockfile change in a follow-up PR rather than rewriting merged history.
• Consider a merge driver for package-lock.json so future conflicts auto-resolve to a clean regen without drama.
• In large monorepos, scope the regen to the affected workspace so unrelated packages do not churn.

Provenance

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

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

Thread query: agent tried to rebase its upgrade PR, hit a package-lock.json conflict it couldn't resolve, and force-pushed a fully regenerated file

TL;DR: