bazelbuild
Globing a deleted directory fails
Description of the bug:
When path/to/project/BUILD contains a glob(["**/*.cs"]) and path/to/project/src/SomeFolder contains various *.cs files, a consequtive bazel build will result in errors when SomeFolder is deleted.
Environment
We are running on windows which could narrow down the impact. Also passing --nowatchfs fixes the error, but is not a solution we would like to push to all our devs.
Errors
For bazel 7.x: error globbing [**/*.cs] - [**/obj/**, **/bin/**] op=FILES: D:/dev/.../SomeFolder (No such file or directory
For bazel 8.x: Inconsistent filesystem operations. Encountered error 'D:/dev/.../SomeFolder (No such file or directory)' but didn't encounter it when doing the same thing earlier in the build The results of the build are not guaranteed to be correct. You should probably run 'bazel clean' and investigate the filesystem inconsistency (likely due to filesystem updates concurrent with the build)
Stack trace
[com.google.devtools.build.lib.packages.StarlarkNativeModule.runGlobOperation] Exception processing includes=[**/*.cs], excludes=[**/obj/**, **/bin/**])
java.io.FileNotFoundException: D:/dev/.../SomeFolder (No such file or directory)
at com.google.devtools.build.lib.vfs.JavaIoFileSystem.getDirectoryEntries(JavaIoFileSystem.java:96)
at com.google.devtools.build.lib.vfs.FileSystem.readdir(FileSystem.java:648)
at com.google.devtools.build.lib.vfs.Path.readdir(Path.java:268)
at com.google.devtools.build.lib.skyframe.DefaultSyscallCache.readdirImpl(DefaultSyscallCache.java:269)
at com.github.benmanes.caffeine.cache.LocalLoadingCache.lambda$newMappingFunction$3(LocalLoadingCache.java:197)
at com.github.benmanes.caffeine.cache.UnboundedLocalCache.lambda$computeIfAbsent$2(UnboundedLocalCache.java:296)
at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(Unknown Source)
at com.github.benmanes.caffeine.cache.UnboundedLocalCache.computeIfAbsent(UnboundedLocalCache.java:292)
at com.github.benmanes.caffeine.cache.LocalCache.computeIfAbsent(LocalCache.java:107)
at com.github.benmanes.caffeine.cache.LocalLoadingCache.get(LocalLoadingCache.java:57)
at com.google.devtools.build.lib.skyframe.DefaultSyscallCache.readdir(DefaultSyscallCache.java:116)
at com.google.devtools.build.lib.vfs.SingleFileSystemSyscallCache.readdir(SingleFileSystemSyscallCache.java:52)
at com.google.devtools.build.lib.skyframe.DirectoryListingStateFunction.compute(DirectoryListingStateFunction.java:66)
at com.google.devtools.build.lib.skyframe.DirectoryListingStateFunction.compute(DirectoryListingStateFunction.java:32)
Which category does this issue belong to?
No response
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
No response
Which operating system are you running Bazel on?
Windows
What is the output of bazel info release?
release 7.4.1
If bazel info release returns development version or (@non-git), tell us how you built Bazel.
No response
What's the output of git remote get-url origin; git rev-parse HEAD ?
If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
@tomdegoede Could you please provide complete steps to reproduce this issue?
@iancha1992 This seems to be a race condition that only occurs in larger codebases. I currently have a small subset of our private monorepo that reproduces the case occasionally. I still have to anonymize this before I am able to share it.
@iancha1992 I have published to repro codebase at https://github.com/tomdegoede/glob-repro. Could you verify that it raised the error as documented in the readme?