-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"unlinkat ([path]) (Directory not empty)" errors with experimental_worker_for_repo_fetching #22680
Labels
P2
We'll consider working on this in future. (Assignee optional)
team-ExternalDeps
External dependency handling, remote repositiories, WORKSPACE file.
type: bug
Comments
I am presently confirming that |
Still on 7.2.0, haven't seen this again with |
I managed to reproduce this via #22748 (comment):
|
@bazel-io fork 7.2.1 |
copybara-service bot
pushed a commit
that referenced
this issue
Jun 19, 2024
`StarlarkBaseExternalContext` now implements `AutoCloseable` and, in `close()`: 1. Cancels all pending async tasks. 2. Awaits their termination. 3. Cleans up the working directory (always for module extensions, on failure for repo rules). 4. Fails if there were pending async tasks in an otherwise successful evaluation. Previously, module extensions didn't do any of those. Repo rules did 1 and 4 and sometimes 3, but not in all cases. This change required replacing the fixed-size thread pool in `DownloadManager` with virtual threads, thereby resolving a TODO about not using a fixed-size thread pool for the `GrpcRemoteDownloader`. Work towards #22680 Work towards #22748 Closes #22772. PiperOrigin-RevId: 644669599 Change-Id: Ib71e5bf346830b92277ac2bd473e11c834cb2624
fmeum
added a commit
to fmeum/bazel
that referenced
this issue
Jun 20, 2024
`StarlarkBaseExternalContext` now implements `AutoCloseable` and, in `close()`: 1. Cancels all pending async tasks. 2. Awaits their termination. 3. Cleans up the working directory (always for module extensions, on failure for repo rules). 4. Fails if there were pending async tasks in an otherwise successful evaluation. Previously, module extensions didn't do any of those. Repo rules did 1 and 4 and sometimes 3, but not in all cases. This change required replacing the fixed-size thread pool in `DownloadManager` with virtual threads, thereby resolving a TODO about not using a fixed-size thread pool for the `GrpcRemoteDownloader`. Work towards bazelbuild#22680 Work towards bazelbuild#22748 Closes bazelbuild#22772. PiperOrigin-RevId: 644669599 Change-Id: Ib71e5bf346830b92277ac2bd473e11c834cb2624
github-merge-queue bot
pushed a commit
that referenced
this issue
Jun 20, 2024
…22814) `StarlarkBaseExternalContext` now implements `AutoCloseable` and, in `close()`: 1. Cancels all pending async tasks. 2. Awaits their termination. 3. Cleans up the working directory (always for module extensions, on failure for repo rules). 4. Fails if there were pending async tasks in an otherwise successful evaluation. Previously, module extensions didn't do any of those. Repo rules did 1 and 4 and sometimes 3, but not in all cases. This change required replacing the fixed-size thread pool in `DownloadManager` with virtual threads, thereby resolving a TODO about not using a fixed-size thread pool for the `GrpcRemoteDownloader`. Work towards #22680 Work towards #22748 Closes #22772 PiperOrigin-RevId: 644669599 Change-Id: Ib71e5bf346830b92277ac2bd473e11c834cb2624 Closes #22775
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
P2
We'll consider working on this in future. (Assignee optional)
team-ExternalDeps
External dependency handling, remote repositiories, WORKSPACE file.
type: bug
Description of the bug:
After upgrading to Bazel 7.2.0 and removing
--experimental_worker_for_repo_fetching=off
from.bazelrc
(because #21803 was fixed), we started to observe failures of the following form:These errors appear to be linked with repository fetch restarts, particularly "fetch interrupted due to memory pressure; restarting". In two of two cases where I have seen this error, it happened in a repo where the repo fetch got restarted, judging by either the presence of that log message or the JSON trace profile.
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?
Linux
What is the output of
bazel info release
?release 7.2.0
If
bazel info release
returnsdevelopment 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
?No response
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?
Bazel Slack discussion: https://bazelbuild.slack.com/archives/CA31HN1T3/p1718057176146129
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: