Execute/ActionResult Rejection Response about remote-apis HOT 8 OPEN

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"?

from remote-apis.

Currently, we reject actions that a) depend on oversized inputs and b) produce oversized outputs. We accomplish this for 'a' by passively ignoring (through findMissingBlobs manipulation) requests until we have a clear channel (the execute Operation response) to present a PRECONDITION_FAILURE or inspire a local fallback in bazel. For 'b' we supply this PRECONDITION_FAILURE as an action result for an oversized output.

Oversized in this case varies by heuristic, but can be thought of as a simple file size: say 1G.

There is future work to systematically apply policies to actions' behaviors, like never accessing above a percentage threshold of their inputs via the filesystem, producing orders of magnitude larger outputs than inputs, executing blacklisted programs, or other abusive behaviors involving resource acquisition - spending a threshold percentage of time blocked on IO, network, or just sleeping, etc.

from remote-apis.

I don't think it's safe to assume that there is an exact 1:1 correspondence between execute and findMissingBlobs calls. Bazel could generate one call to findMissingBlobs for a Bazel action, but make multiple execute calls for different subsets of inputs.

That said, some of the other policies sound intriguing.

from remote-apis.

I don't think it's safe to assume that there is an exact 1:1 correspondence between execute and findMissingBlobs calls. Bazel could generate one call to findMissingBlobs for a Bazel action, but make multiple execute calls for different subsets of inputs.

Precisely why I want a way to tell the client to go away directly. These are all hacks.

from remote-apis.

from remote-apis.

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 this case, we interpret it to mean that there were missing inputs, and that uploading more files would fix the issue). I think that INVALID_INPUT is probably more accurate--the action simply is not suitable for remote execution.

That still leaves us with the problem of separating this type of invalid input from other types. I'm not sure that Java supports adding details to a status object.

from remote-apis.

I'm fine with using INVALID_INPUT, sure. I don't think that changes anything materially (it's still a non-retriable error that the client can fall back or exit out as it sees fit).

from remote-apis.

@bergsieker, @EricBurnett, did you mean INVALID_ARGUMENT? If so, that seems fair to me. @werkt, assuming you are still interested in having this, care to raise a documentation PR? The error is already listed as one that can be returned, as such I think it is only a clarification.

from remote-apis.