-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Investigate behavior of interrupted execution of long-to-execute repository rules #8993
Labels
P3
We're not considering working on this, but happy to review a PR. (No assignee)
team-ExternalDeps
External dependency handling, remote repositiories, WORKSPACE file.
type: bug
Comments
irengrig
added
P1
I'll work on this now. (Assignee required)
team-ExternalDeps
External dependency handling, remote repositiories, WORKSPACE file.
labels
Jul 26, 2019
/cc @laurentlb |
meisterT
added
untriaged
and removed
P1
I'll work on this now. (Assignee required)
labels
May 12, 2020
philwo
added
the
team-OSS
Issues for the Bazel OSS team: installation, release processBazel packaging, website
label
Jun 15, 2020
Is there any update on this? In the meantime we've modified some of our repository rules to output a sentinel file when they successfully complete, and we check for that file's existence in our bazel wrapper. |
philwo
added
P3
We're not considering working on this, but happy to review a PR. (No assignee)
type: bug
and removed
untriaged
labels
Feb 8, 2021
fmeum
added a commit
to fmeum/bazel
that referenced
this issue
Nov 19, 2021
Fetching a repository is a long-running operation that can easily be interrupted. If it is and the marker file exists on disk, a new evaluation of the RepositoryDelegatorFunction may treat this repository as valid even though it is in an inconsistent state. Clearing the marker file before initiating the fetch and only recreating it after the fetch is complete prevents this scenario. Fixes bazelbuild#8993.
fmeum
added a commit
to fmeum/bazel
that referenced
this issue
Nov 24, 2021
Fetching a repository is a long-running operation that can easily be interrupted. If it is and the marker file exists on disk, a new evaluation of the RepositoryDelegatorFunction may treat this repository as valid even though it is in an inconsistent state. Clearing the marker file before initiating the fetch and only recreating it after the fetch is complete prevents this scenario. Fixes bazelbuild#8993. Closes bazelbuild#14302. PiperOrigin-RevId: 412101756
fmeum
added a commit
to fmeum/bazel
that referenced
this issue
Nov 24, 2021
Fetching a repository is a long-running operation that can easily be interrupted. If it is and the marker file exists on disk, a new evaluation of the RepositoryDelegatorFunction may treat this repository as valid even though it is in an inconsistent state. Clearing the marker file before initiating the fetch and only recreating it after the fetch is complete prevents this scenario. Fixes bazelbuild#8993. Closes bazelbuild#14302. PiperOrigin-RevId: 412101756
meteorcloudy
pushed a commit
that referenced
this issue
Nov 25, 2021
Fetching a repository is a long-running operation that can easily be interrupted. If it is and the marker file exists on disk, a new evaluation of the RepositoryDelegatorFunction may treat this repository as valid even though it is in an inconsistent state. Clearing the marker file before initiating the fetch and only recreating it after the fetch is complete prevents this scenario. Fixes #8993. Closes #14302. PiperOrigin-RevId: 412101756
meteorcloudy
pushed a commit
that referenced
this issue
Nov 25, 2021
Fetching a repository is a long-running operation that can easily be interrupted. If it is and the marker file exists on disk, a new evaluation of the RepositoryDelegatorFunction may treat this repository as valid even though it is in an inconsistent state. Clearing the marker file before initiating the fetch and only recreating it after the fetch is complete prevents this scenario. Fixes #8993. Closes #14302. PiperOrigin-RevId: 412101756
philwo
removed
the
team-OSS
Issues for the Bazel OSS team: installation, release processBazel packaging, website
label
Nov 29, 2021
Bencodes
pushed a commit
to Bencodes/bazel
that referenced
this issue
Jan 10, 2022
Fetching a repository is a long-running operation that can easily be interrupted. If it is and the marker file exists on disk, a new evaluation of the RepositoryDelegatorFunction may treat this repository as valid even though it is in an inconsistent state. Clearing the marker file before initiating the fetch and only recreating it after the fetch is complete prevents this scenario. Fixes bazelbuild#8993. Closes bazelbuild#14302. PiperOrigin-RevId: 412101756
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
P3
We're not considering working on this, but happy to review a PR. (No assignee)
team-ExternalDeps
External dependency handling, remote repositiories, WORKSPACE file.
type: bug
Copying the link and text of original [description:]
(bazel-contrib/rules_nodejs#802 (comment))
Canceling a build at its loading phase will also trigger this.
The first build:
The second build:
My speculation is that repository_ctx doesn't have a way to tell if a repository has been fully loaded or not, so it will use a corrupted external repository without loading it again.
The text was updated successfully, but these errors were encountered: