Steven Bergsieker

The intersection between remote-apis (which is technically independent of Bazel, despite being hosted there), Bazel, and support tooling has always been tricky. We definitely shouldn't have Bazel-specific logic in this...

> I love this PR, thank you for the bzlmod support! One request before this is merged.. Can we rename the `java_proto_library` rules? I'd like to reserve the `_java_grpc` suffix...

Hi Seth, Thanks for sharing this with the group! I think your workaround is reasonable, and is actually more-or-less what's intended by the design of the CAS API. We intentionally...

> > Are you referring to UpdateActionResult()/GetActionResult() in ActionCacheServer.java? > > Is that ActionCacheServer.java in bazel-buildfarm? If so... yes? > > GetActionResult() is only permitted to return ActionResults if all...

Yeah, I think we're basically stuck with these generated bindings for now, and can reevaluate for v3. I'd still prefer it if we didn't have them here, but there's not...

Adding to list of issues to consider for v3. Not clear what the right answer is, but we can consider it at that time.

I let this sit for far too long, resulting in a second PR for converting to bzlmod (https://github.com/bazelbuild/remote-apis/pull/307). I ended up merging that one instead, simply because it was more...

You are correct that the current API does not specify an ordering. Note that there's no ambiguity here: each result includes a digest, so the client can understand which bytes/status...

George, can you provide a driving use case for when this would be useful? What does it mean (to you) for an action to be "unsuitable"?

I think that PRECONDITION_FAILURE is the wrong thing to return in this case--it implies that there's something about the *system* that can be changed to make the action acceptable (in...