It seems that external process can modify Cargo.lock during run of check action

[Mingun]

I investigating the problem that started from tafia/quick-xml#562.

When I tried to reproduce the error I found, that I cannot do that. After some time of digging and creating issues here and there I realized, that the problem probably because I use the VSCode integrated terminal and VSCode keeps rust-analyzer process running.

When I try to prepare clean testcase for rust-lang/cargo#11765 I noted, that the Cargo.lock file of my test project is restored almost immediately after I delete it (and after that contains the latest versions).

After some observations I saw, that the file being is restored due to rust-analyzer activity. So the working hypothesis that rust-analyzer rewrites Cargo.lock while cargo-minimal-versions doing it work (if I understand correctly, it deletes the old file and writes the new, maybe there a race condition with other process).

As a result, cargo minimal-versions check command sometimes reports no errors where it should.

[taiki-e]

Well, it is a known problem that r-a does not interact well with cargo commands running simultaneously in the terminal. (There are several cases, but target directory conflicts are maybe the most well-known case. r-a issue 14204 is one of the other cases.)

In the "build/check for library" case, the approach described here should work around this (no one is working on implementing it yet, though), but it is not clear if it is possible to work around this problem on our end in the "build/check for binary" case. (Is there any way to delay r-a from executing cargo-metadata?)

(In any case, I would personally recommend running cargo-minimal-versions in CI, as it can be easily set up in CI.)

[taiki-e]

Is there any way to delay r-a from executing cargo-metadata?

As another way, if we can avoid cargo-metadata changing the lockfile, we can also fix this problem, because the underlying problem¹ here is that the lockfile change by the cargo-metadata called by r-a conflicts with the lockfile change by the cargo-update called by cargo-minimal-versions.

Related: rust-lang/cargo#10096

Footnotes

1. I think cargo-minimal-versions changing the manifest is not the underlying problem here; even if cargo-minimal-versions did not change the manifest, the user could trigger the same problem by just saving the file. ↩