Skip to content
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

Closed
irengrig opened this issue Jul 26, 2019 · 2 comments
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
Copy link
Contributor

irengrig commented Jul 26, 2019

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:

Loading:
Loading: 0 packages loaded
Loading: 0 packages loaded
Loading: 0 packages loaded
# Received cancellation signal, interrupting

The second build:

Loading:
Loading: 0 packages loaded
ERROR: error loading package '': in /var/lib/buildkite-agent/builds/buildkite-agents-preemptible-nzjp-2/<redacted>/javascript/npm.bzl: Every .bzl file must have a corresponding package, but '@npm//:install_bazel_dependencies.bzl' does not have one. Please create a BUILD file in the same or any parent directory. Note that this BUILD file does not need to do anything except exist.
ERROR: error loading package '': in /var/lib/buildkite-agent/builds/buildkite-agents-preemptible-nzjp-2/<redacted>/javascript/npm.bzl: Every .bzl file must have a corresponding package, but '@npm//:install_bazel_dependencies.bzl' does not have one. Please create a BUILD file in the same or any parent directory. Note that this BUILD file does not need to do anything except exist.
INFO: Elapsed time: 0.200s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded)
INFO: Build Event Protocol files produced successfully.
FAILED: Build did NOT complete successfully (0 packages loaded)

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.

@irengrig irengrig added P1 I'll work on this now. (Assignee required) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. labels Jul 26, 2019
@irengrig irengrig self-assigned this Jul 26, 2019
@irengrig
Copy link
Contributor Author

/cc @laurentlb

@meisterT meisterT added untriaged and removed P1 I'll work on this now. (Assignee required) labels May 12, 2020
@philwo philwo added the team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website label Jun 15, 2020
@uri-canva
Copy link
Contributor

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 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 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
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants