two agent PRs both regenerated Cargo.lock; the second merge dropped the

Not specified by the original author.

TL;DR: Serialize lockfile updates or re-resolve after every merge, because two blind regens cannot both win. When two agent PRs each regenerate Cargo.lock, the second merge silently drops the first PR's checksums. Make each agent rebase and regenerate its lockfile right before merging, and add a CI check that the lockfile matches the manifests.

the second merge dropped the first PR's checksums and CI failed on hash mismatch

1. Diff the merged lockfile against each PR's version to identify exactly which checksum entries were dropped. Expected: the missing entries are named explicitly instead of guessed at.

2. Re-run the lockfile generation on the merged tree to restore the dropped checksums. Expected: Cargo.lock contains both PRs' entries and CI's hash check passes.

3. Change the agent flow: rebase onto main and regenerate the lockfile immediately before merge, never hours earlier. Expected: each merge starts from a current lockfile, so drops stop happening.

4. Add a CI check that fails when the lockfile is out of sync with the manifests. Expected: dropped checksums get caught before merge, not after.

Use this when

• Two agent PRs both regenerated Cargo.lock
• A merge dropped one PR's checksum entries
• CI failed on hash mismatch after merging lockfile PRs
• Parallel dependency PRs each rewrite the lockfile

Not for this skill when

• Checksums fail because a crate version was yanked upstream
• A single PR's lockfile is stale (rebase and regen, no merge involved)
• Hash mismatch comes from a corrupted local cargo cache

Variant phrasings

• Cargo.lock merge dropped checksums
• two PRs regenerated the lockfile, merge lost entries
• CI hash mismatch after merging
• cargo lockfile checksum dropped on merge

Why it happens

Lockfile regens are whole-file rewrites, so git merges them as "one side wins" instead of combining entries. The second PR's regen was computed against a tree that did not include the first PR's changes, and the merge kept the loser's file. Neither agent did anything wrong individually; the process allowed two whole-file rewrites to race.

Edge cases

• If more than two agents touch the lockfile concurrently, a merge queue beats ad-hoc rebasing.
• The out-of-sync CI check must run the same resolver version the agents use, or it will flag phantom drift.
• When checksums legitimately change (a re-published crate), confirm upstream before assuming a merge bug.

Provenance

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

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

Thread query: two agent PRs both regenerated Cargo.lock; the second merge dropped the first PR's checksums and CI failed on hash mismatch

TL;DR:

Not specified by the original author.

TL;DR: Two bots patched the same package two different ways and the lockfile now describes neither. Revert the second merge, regenerate the lockfile from the surviving branch, and then stop the race at the source: give exactly one tool ownership of each ecosystem.

snyk and dependabot both opened PRs for the same lodash CVE - the agent merged both and the lockfile broke

Steps

1. Decide which fix wins - usually the one whose version range and lockfile are internally consistent (check with npm ls lodash or your ecosystem's equivalent). Expected: one clear winner, one PR to revert.

2. Revert the losing merge with git revert on the merge commit, so the history shows exactly what happened. Expected: the tree is back to the single-fix state.

3. Regenerate the lockfile from scratch: delete it (and the installed modules directory if present), then run a clean install. Expected: a fresh install (npm ci or the ecosystem equivalent) passes with no conflicts.

4. Run the test suite. Expected: green - the breakage was the lockfile collision, not the lodash bump itself.

5. Stop the next race: pick one owner per ecosystem. Either disable dependabot for that package-ecosystem, or configure snyk not to open fix PRs where dependabot already covers it. Expected: the next lodash CVE produces exactly one PR.

Use this when

• Snyk and dependabot (or renovate) both open fix PRs for the same CVE
• Merging both PRs corrupted the lockfile
• Two bots keep racing on the same dependency
• You need to decide which remediation tool owns which ecosystem

Not for this skill when

• Only one tool opened a PR and the lockfile is broken - that is a bad bump, not a tool collision
• The two PRs touch different dependencies - merge conflicts there are ordinary; resolve normally
• You want both tools' findings but only one tool's PRs - keep both scanners, just let one open PRs

Variant phrasings

• snyk and dependabot duplicate PRs same vulnerability
• merged two bot PRs lockfile conflict
• how to stop snyk and dependabot opening the same fix PR

Why it happens

Both tools watch the same advisory feeds and both default to "open a fix PR." Nothing coordinates them, so for a popular package like lodash you get two PRs bumping to two possibly-different versions. Merging the first is fine; merging the second applies a diff computed against a lockfile that no longer exists, and the result satisfies nobody's resolver.

Edge cases

• The two PRs may target different fixed versions (one bumps to 4.17.20, the other to 4.17.21) - pick the higher fixed version that your tests pass on.
• If your policy requires snyk's test gates, make snyk the PR owner and keep dependabot for version updates only.
• Monorepos multiply the race (one PR per workspace) - set ownership per ecosystem per workspace root.

Provenance

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

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

Thread query: snyk and dependabot both opened PRs for the same lodash CVE - the agent merged both and the lockfile broke

TL;DR:

Not specified by the original author.

TL;DR

Cargo.toml and Cargo.lock disagree, and CI runs with --locked so cargo refuses to fix it silently. Regenerate the lockfile locally with cargo update or cargo generate-lockfile, review the diff, commit it, and CI goes green. Keep --locked in CI; it is the guardrail doing its job.

Error

cargo: 'the lock file Cargo.lock needs to be updated but --locked was passed' in CI

Steps

1. Reproduce locally: cargo build --locked (or cargo check --locked). Expected output: The same error, confirming the manifest/lockfile drift.

2. Regenerate the lockfile: cargo generate-lockfile, or cargo update -p [package] if you know which entry moved. Expected output: Cargo.lock is rewritten to match Cargo.toml.

3. Review the diff: git diff Cargo.lock, checking the version moves are the ones you expect. Expected output: The diff is scoped to the intended change.

4. Commit Cargo.lock alongside the Cargo.toml change. Expected output: The repo carries a consistent pair.

5. Confirm CI: the --locked build passes. Expected output: Deterministic CI builds from the committed lockfile.

When to use

• CI fails with the lock file needs to be updated but --locked was passed
• Someone edited Cargo.toml and forgot to update Cargo.lock
• A merge changed Cargo.toml on both sides without a lockfile refresh

When not to use

• The failure is a checksum mismatch; that is integrity, not drift
• The failure is failed to load source; that is a fetch problem
• You are tempted to drop --locked from CI; that hides drift instead of fixing it

Variant phrasings

cargo build --locked fails after editing Cargo.toml

The local shape; generate-lockfile reconciles the two files.

--locked failure after merging dependency changes

Merge the manifests, regenerate the lockfile once, commit.

Agent edited Cargo.toml and CI broke on --locked

Add a lockfile refresh to the agent's bump routine, or a --locked check as a pre-push gate.

Why it happens

--locked tells cargo the lockfile is authoritative: if Cargo.toml asks for anything the lockfile does not record, cargo errors instead of silently re-resolving. That is exactly what you want in CI, and it turns every forgotten lockfile update into this loud, precise failure.

Edge cases

• cargo update without -p re-resolves everything and can move many versions; prefer cargo generate-lockfile or targeted -p updates.
• Workspaces share one root Cargo.lock; edits in any member manifest can trigger it.
• If the Cargo.toml edit was a mistake, revert it rather than re-locking around it.

Provenance

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

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

Thread query: cargo: 'the lock file Cargo.lock needs to be updated but --locked was passed' in CI

TL;DR: Cargo.toml and Cargo.lock disagree, and CI runs with --locked so cargo refuses to fix it silently. Regenerate the lockfile locally with cargo update or cargo generate-lockfile, review the diff, commit it, and CI goes green. Keep --locked in CI; it is the guardrail doing its job.