Bazel Client fails to "fail early" in the event of a test failure with --notest_keep_going on buildbarn remote execution
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 72
Description
### Description of the bug:
When you run bazel test //... with buildbarn remote execution & --notest_keep_going, the expected behavior is to stop and fail early. In the event of a failure, Buildbarn will allow the action to run for up to one minute (potentially allowing Bazel to reconnect). However, the exepcted action is for bazel to shut down and fail early (not reconnect to buildbarn)
### Which category does this issue belong to?
Remote Execution
### What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
`bazel test //... --notest_keep_going` against a deployment of buildbarn (could spin up a local buildbarn cluster https://github.com/buildbarn/bb-deployments)
with a known test failure and you'll see that bazel fails to stop early on first test failure
### Which operating system are you running Bazel on?
ubuntu 20.04 linux
### What is the output of `bazel info 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` ?
```text
```
### 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_
Contributor guide
Research direction
Start by running `bazel test //... --notest_keep_going` with Bazel 7.4.1 on Ubuntu 20.04 against a Buildbarn deployment containing a known test failure. Inspect the Bazel client’s remote-execution behavior around the first failed test and compare it with the expected early shutdown. Done means Bazel stops promptly and does not reconnect or allow the action to continue for up to one minute.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- build-system, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100