Prevent FileNotFoundException when reading .lastUpdated tracking files

[bade7n]

In our CI pipelines we are encountering a substantial number of exceptions like:

[main] [WARNING] Failed to read tracking file '/home/builduser/.m2/repository/cached/central-proxy/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar.lastUpdated'
java.io.FileNotFoundException: /home/builduser/.m2/repository/cached/central-proxy/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar.lastUpdated (No such file or directory)
    at java.io.FileInputStream.open0 (Native Method)
    at java.io.FileInputStream.open (FileInputStream.java:219)
    at java.io.FileInputStream.<init> (FileInputStream.java:157)
    at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.read (DefaultTrackingFileManager.java:58)
    ...

These errors occur when a .lastUpdated tracking file is missing during concurrent repository access, leading the build to fail even though the file absence is harmless.

This patch introduces a safe fallback by catching FileNotFoundException in DefaultTrackingFileManager.read(). Missing or concurrently removed tracking files are now treated as non-fatal, preventing unnecessary build failures.

[cstamas]

Can you tell us more, the CI where you get substantial number of FNFEx:

• what OS (storage kind as well, if something "unusual")
• what Java version/provider
• what Maven version

[bade7n]

Ubuntu 22.04.5 LTS
Java version: 11.0.28, vendor: Amazon.com Inc., runtime: /usr/lib/jvm/java-11-amazon-corretto
We run multiple Maven build in parallel but all of them use Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)

[cstamas]

Thanks!
Any particular reason why 3.9.6? Since then there is 3.9.11 with a TON of fixed bugs...

[cstamas]

Related: #1003
It is such a shame that one OS problem affects the rest... IMO the proper solution here (or proper OS) is just use of atomic FS move (write to tmp, move atomically to its place), this file is never deleted, and should never be "gone" due concurrent use.

[bade7n]

No specific reason, I can upgrade the version to 3.9.11 if you say that.
I might be wrong but I haven't found anything what could fix that issue in recent commits of 3.9.x.

[cstamas]

I am -1 on this PR, and here is why:

My plan is this:

• maven (should be backported to 3.9.x too): Drop legacy duplicated code maven#11494 (drop the duplicated code, reason for file locking, and call in into Resolver component)
• resolver TrackingFileManager changes #1692 (fix out of the band deletion, I was wrong about "should never be gone", it is "gone")

I am still open to add FNFEx to ignored exceptions though.

[bade7n]

Ignoring the FNF would resolve the issue for us.

Should I remove the tests from this PR and keep only the fix, or should this change go into master/some other branch instead?

[cstamas]

Pls take a peek at #1692

IMO, this should fix your issue; I will backport this fix from master to 1.9.x as well, so both, Maven 4-rc-6 and Maven 3.9.12 should have it.

[cstamas]

Superseded by #1692 and #1695