Bazel retry attribute: automatic idempotency enforcement for remote actions

Question

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?

Tasadduq Burney · Answer

Answer
Bazel should not automatically assume that every retried remote action is idempotent. Instead, it should require rule authors to explicitly declare when an action is safe to retry (opt‑in) or to disable retries for actions that have external side effects.
Confirmed facts

Bazel retries failed remote actions by executing each attempt in a fresh temporary sandbox and only promotes the outputs of the successful attempt.
The sandbox prevents duplicate file outputs but does not isolate external interactions such as API calls or shared file updates.
Current Bazel releases do not provide a built‑in attribute to mark an action as idempotent; proposals exist for an optional idempotent = True flag.

Likely explanation
If Bazel treated all retries as idempotent, a failing action that writes to an external service could be invoked multiple times, causing duplicate writes or other unintended side effects. Requiring an explicit declaration prevents this class of bugs while still allowing safe, pure actions to benefit from retries.
Steps for this case

Determine whether the action performs any external side effects (e.g., network calls, writes to shared storage).
If side effects are present, either disable retries via execution_requirements or await a future idempotent = True attribute that gates retries.
If the action is pure (no external effects), rely on Bazel’s sandbox‑based retry mechanism; no additional annotation is needed.

Please confirm whether the action in question performs external side effects; this detail determines whether an opt‑in idempotent attribute is required.

Bazel retry attribute: automatic idempotency enforcement for remote actions

1 answer

Answer

Confirmed facts

Likely explanation

Steps for this case

Your perspective belongs here.

0 question comments