Execute/ActionResult Rejection Response

Executions are capable of depending upon or producing invalid definitions or products, respectively.

Currently, the remote system has limited options for influencing the behavior of the client, exemplified here with bazel. This sequence is *very* complicated and boils down to:

1. Any stock RemoteRetrier 'retriable' status codes in the ExecuteResponse status field trigger a waitExecution.
1. A FAILED_PRECONDITION status in ExecuteResponse with an array of ExecuteResponse->Status->Details[PreconditionFailures] with only "MISSING" types triggers a restart of the execution loop, starting with ensureInputsPresent, if the outer execution retrier has not been exhausted.

If the execution retrier is exhausted, the client will revert to fallback behavior, either local execution or failing.

Currently, a remote instance may identify subsequent requests on the action (pursuant to RequestMetadata) and coordinate a short-circuited response (of more like [2] above).

But this practice is awkward, and depends upon a reasonable retry count and hopefully no exponential backoff for any sub request. Can we provide/standardize a status like GOAWAY that indicates that an action is unsuitable for remote execution or caching?

No files or tests are named. Start by reviewing the ExecuteResponse status and Details handling, along with RequestMetadata-based action identification, to understand the current retry and waitExecution behavior. Done would require an agreed standardized status and documented client behavior for rejecting remote execution or caching.

Written by the indexing model from the issue text.