Skip to content

Conversation

bazel-io
Copy link
Member

The error message observed in #26713 is consistent with FileChannel#open failing because the given path doesn't exist. This could happen if one Bazel process observed that !entryDir.isDirectory(), which is true if the path doesn't exist, and proceeded to delete the path while another process had just created the directory and is now opening the channel. Since the entry dir is never expected to be an existing non-directory unless the cache has been corrupted, this logic can be removed.

Another possible source of IOException during normal operation is on an interrupt (such as the user hitting Ctrl+C). Instead, follow Skyframe best practices by surfacing this as an InterruptedException instead of a FileLockInterruptionException.

Also document that concurrent use on the same path is not supported (it results in an OverlappingFileLockException if the lock is already held, regardless of whether that is in shared or exclusive mode) and why the current usages are safe.

Fixes #26713

Closes #26914.

PiperOrigin-RevId: 805338728
Change-Id: Ie808ebe6113b935180b93c21679d5398aa168802

Commit ca1cbfe

The error message observed in bazelbuild#26713 is consistent with `FileChannel#open` failing because the given path doesn't exist. This could happen if one Bazel process observed that `!entryDir.isDirectory()`, which is true if the path doesn't exist, and proceeded to delete the path while another process had just created the directory and is now opening the channel. Since the entry dir is never expected to be an existing non-directory unless the cache has been corrupted, this logic can be removed.

Another possible source of `IOException` during normal operation is on an interrupt (such as the user hitting Ctrl+C). Instead, follow Skyframe best practices by surfacing this as an `InterruptedException` instead of a `FileLockInterruptionException`.

Also document that concurrent use on the same path is not supported (it results in an `OverlappingFileLockException` if the lock is already held, regardless of whether that is in shared or exclusive mode) and why the current usages are safe.

Fixes bazelbuild#26713

Closes bazelbuild#26914.

PiperOrigin-RevId: 805338728
Change-Id: Ie808ebe6113b935180b93c21679d5398aa168802
@bazel-io bazel-io requested a review from a team as a code owner September 10, 2025 17:57
@bazel-io bazel-io added team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. awaiting-review PR is awaiting review from an assigned reviewer labels Sep 10, 2025
@iancha1992 iancha1992 requested a review from Wyverald September 10, 2025 17:57
@iancha1992 iancha1992 added this pull request to the merge queue Sep 10, 2025
Merged via the queue into bazelbuild:release-8.4.1 with commit 8c1ff19 Sep 10, 2025
47 checks passed
@github-actions github-actions bot removed the awaiting-review PR is awaiting review from an assigned reviewer label Sep 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants