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

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.

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

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

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