Current Behavior

I’m finding that in certain circumstances, the filter assigned to a FileCollection is ignored.

In DefaultFileSystemAccess.snapshot there is an early exit here to check for existing FileSystemLocationSnapshots, and if one is found, then the snapshot is used, regardless of whether a filter was passed to the snapshot() function

Normally this case doesn’t trigger, because there are other early exits in readSnapshotFromLocation() such as here which do apply the filter, and there is a lock in readSnapshotFromLocation() to try to prevent computing multiple snapshots of the same directory at a time (see comment).

However, if DefaultFileSystemAccess simultaneously tries to load information about a parent and child directory at the same time, then it is possible that updates of the parent directory in the virtual file system will also cause corresponding updates of the child directory, even while DefaultFileSystemAccess holds a lock on the child directory. These concurrent updates can then trigger the ignoring of a FileCollection's filter.

Expected Behavior

It would be nice if the filter assigned to a FileCollection weren't ignored

Context (optional)

In AndroidX we've been observing our compileKotlin tasks to be intermittently out-of-date: https://issuetracker.google.com/issues/321949384 and this seems to be the cause

Steps to Reproduce

I've uploaded a repro case to https://github.com/mathjeff/gradle-samples-2/tree/main/snapshot-wrong

Because reproducing this issue involves a race condition, I've also uploaded a test Gradle change that exacerbates the race condition by adding an additional hard coded sleep for a specific path (the child path) at master...mathjeff:gradle:test-exacerbate-snapshot-race-condition

The test.sh script in the repro case takes care of applying this change before running the test

Gradle version

8.7.0

Build scan URL (optional)

No response

Your Environment (optional)

No response