Bazel retry attribute: automatic idempotency enforcement for remote actions

When Bazel retries a failed action under a remote strategy, it redirects each attempt to a distinct temporary sandbox and only moves the successful outputs to the final output tree. This prevents duplicate files from appearing, but it does not guarantee that the action’s side effects—such as updates to external services or shared files—are harmless if repeated.

The unresolved design decision is whether Bazel should automatically treat every retried action as idempotent, thereby allowing retries without additional safeguards, or whether it should require rule authors to explicitly declare an action as idempotent (e.g., via a new attribute) before permitting retries that could affect external state.

Should Bazel assume idempotency for all retried actions? Should a rule‑level opt‑in/out mechanism control retry safety for side‑effecting actions? How should Bazel communicate the retry‑safety contract to users?