Provider‑declared retryable actions versus Terraform retry block: avoiding duplicate writes on transient errors

Goal

Ensure that Terraform retries a provider operation after a transient error without creating duplicate resources when the underlying API call is not idempotent.

Constraints and uncertainty

• Providers can mark individual CRUD actions as retryable via the SDK’s Retryable field, which assumes the provider implements idempotency for those actions.
• If an action is not marked retryable, Terraform performs no automatic retries; users must handle retries externally, which can cause duplicate writes if the action is not idempotent.
• The experimental retry block introduced in Terraform 1.5 lets users configure attempt counts and back‑off, but it does not provide idempotency guarantees—safety still depends on the provider.
• An open discussion (issue #31284) considers whether Terraform should automatically generate idempotency tokens for AWS‑style APIs on retryable actions, shifting the burden from providers to core, but the proposal is still unresolved.

1. Should Terraform automatically inject idempotency tokens for retryable actions when a provider does not supply them?
2. Is it safer to rely on provider‑declared retryable flags or to use the experimental retry block with external idempotency handling?
3. What verification approach can confirm that a retry does not produce duplicate writes given the current Terraform behavior?