[A-G0D]

generate-lockfiles reads the existing lockfile to plan a uv sync and to compute the dependency diff, so a malformed lockfile failed with TOMLDecodeError instead of being overwritten. Malformed existing lockfiles are now treated as absent: the sync starts from scratch and the diff sees no old dependencies. I added a regression test that corrupts an existing uv lockfile and reruns generation with --sync, and ran pants test, pants lint, and pants check on the touched files.

Fixes #23706.

I used DeepSeek V4 to draft this patch; I reproduced the bug and ran the tests locally.

[benjyw]

Thanks for the contribution. We've just branched for 2.34.x, so merging this pull request now will come out in 2.35.x, please move the release notes updates to docs/notes/2.35.x.md if that's appropriate.

Actually the notes can stay in 2.34.x because I will backport this into the 2.34.x branch.

[benjyw]

Looks good, thanks for the fix.

This will fix the annoying case where there is a merge conflict in the lockfile, so the conflict markers malform the TOML, and you want to resolve it by overwriting it. Today you have to first resolve the conflict, at least by accepting one or the other side of it.

[WorkerPants]

I tried to automatically cherry-pick this change back to each relevant milestone, so that it is available in those older releases of Pants.

✔️ 2.34.x

Successfully opened #23760.

---

Thanks again for your contributions!

🤖 Beep Boop here's my run link

[sureshjoshi]

Is this a good idea? This feels suss to me.

How do lockfiles get malformed? If I think I have a lockfile, and that just gets ignored and re-built, that's a HUGE WTF to me.

If it throws an error, I can just delete the lockfile and re-run.

[benjyw]

Well, there are two layers here - we parse the TOML ourselves for an unimportant reason (to estimate the number of deps), but we can squelch that lower down. Then we would pass malformed toml to uv and it would choke on it. Which is what happens today with a pex lockfile, so I suppose we should be consistent.

This is only relevant with generate-lockfiles --sync, where you're asking to incrementally update something that isn't a valid lockfile. With this change that will become a full regeneration (which is the same as deleting the lockfile and rerunning).

I could be convinced that it's better to take the user literally and fail, but it's annoying when you have many lockfiles with merge conflicts and you want to overwrite them if they do (but not if they don't). I suppose this could be an option, like --rewrite-malformed-lockfiles, that would be a more cautious approach.

[benjyw]

Is this a good idea? This feels suss to me.

How do lockfiles get malformed? If I think I have a lockfile, and that just gets ignored and re-built, that's a HUGE WTF to me.

If it throws an error, I can just delete the lockfile and re-run.

OK, this takes away the one case where it differed from pex lockfiles: #23763