-
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
Bazel uploads AC entries that reference non-existent (zero-size) CAS blob #11063
Comments
Relatedly, I've also received reports that Bazel does not upload empty files that are specified inside input roots of build actions. Note that what Bazel does would be perfectly fine, as long as we make sure that the REv2 specification captures this. Right now REv2 mentions no such thing. |
Submitted a PR to clarify this in the spec: bazelbuild/remote-apis#131 |
I think this issue can be closed now, as bazelbuild/remote-apis#131 has been merged. |
Yep, closing! |
This behavior is a side-effect of cc2b3ec:
IIUC, the change didn't intend to optimize away uploading zero-sized blob. Otherwise, we should add the special case handling at That said, the behavior is existed for a long time and the spec is updated accordingly. I am going to add the special case handling at |
An unintended side-effect of change cc2b3ec is that zero-sized blob won't be uploaded to gRPC cache. However, the behavior is existed for a long time and the REAPI spec is also updated accordingly. This change makes the behavior explicit and brings it to other remote cache backends. Context #11063. Fixes #13349. Closes #13594. PiperOrigin-RevId: 384457129
An unintended side-effect of change cc2b3ec is that zero-sized blob won't be uploaded to gRPC cache. However, the behavior is existed for a long time and the REAPI spec is also updated accordingly. This change makes the behavior explicit and brings it to other remote cache backends. Context bazelbuild#11063. Fixes bazelbuild#13349. Closes bazelbuild#13594. PiperOrigin-RevId: 384457129
An unintended side-effect of change cc2b3ec is that zero-sized blob won't be uploaded to gRPC cache. However, the behavior is existed for a long time and the REAPI spec is also updated accordingly. This change makes the behavior explicit and brings it to other remote cache backends. Context bazelbuild#11063. Fixes bazelbuild#13349. Closes bazelbuild#13594. PiperOrigin-RevId: 384457129
An unintended side-effect of change cc2b3ec is that zero-sized blob won't be uploaded to gRPC cache. However, the behavior is existed for a long time and the REAPI spec is also updated accordingly. This change makes the behavior explicit and brings it to other remote cache backends. Context bazelbuild#11063. Fixes bazelbuild#13349. Closes bazelbuild#13594. PiperOrigin-RevId: 384457129
An unintended side-effect of change cc2b3ec is that zero-sized blob won't be uploaded to gRPC cache. However, the behavior is existed for a long time and the REAPI spec is also updated accordingly. This change makes the behavior explicit and brings it to other remote cache backends. Context bazelbuild#11063. Fixes bazelbuild#13349. Closes bazelbuild#13594. PiperOrigin-RevId: 384457129
An unintended side-effect of change cc2b3ec is that zero-sized blob won't be uploaded to gRPC cache. However, the behavior is existed for a long time and the REAPI spec is also updated accordingly. This change makes the behavior explicit and brings it to other remote cache backends. Context bazelbuild#11063. Fixes bazelbuild#13349. Closes bazelbuild#13594. PiperOrigin-RevId: 384457129
An unintended side-effect of change cc2b3ecb9283ebdb297fc3fb6407f4697c850ac2 is that zero-sized blob won't be uploaded to gRPC cache. However, the behavior is existed for a long time and the REAPI spec is also updated accordingly. This change makes the behavior explicit and brings it to other remote cache backends. Context bazelbuild/bazel#11063. Fixes bazelbuild/bazel#13349. Closes #13594. PiperOrigin-RevId: 384457129
Description of the problem / feature request:
Bazel remote cache grpc backend seems to optimize away uploading the zero-sized CAS blob (sha256 = e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855). This means that all remote cache implementations must add special logic to handle that digest, for example: buchgr/bazel-remote#233
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
I'm running buildbarn/bb-storage@fb0be44 as a remote cache at grpc://localhost:9092.
Here is the decoded remote grpc log:
Click to expand
The log shows that even though the remote cache reports e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 as missing, bazel does not attempt to upload it. Yet, it is referencing it from the ActionResult messages that it uploads.
In normal use this would not be noticed, since on a remote cache hit, I believe bazel grpc cache backend will notice that the referenced CAS blob has zero size and will not attempt to download it. However, if I try to consume the "corrupt" AC entry using the http protocol, bazel will try to download the e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 CAS blob, gets back 404, and will fall back to local execution.
What operating system are you running Bazel on?
What's the output of
bazel info release
?release 2.2.0
Have you found anything relevant by searching the web?
Seems that some remote cache implementations have added special handling for this, see e.g. buchgr/bazel-remote#233
The text was updated successfully, but these errors were encountered: