Automatic Retry

Overview

Automatic Retry is a client or service behavior that repeats a failed or indeterminate operation without requiring a person to initiate each new attempt. A retry is safe only when the failure is transient and the operation is idempotent or protected against duplicate effects.

The principal risks include duplicate charges, retry storms, amplified outages, delayed failure visibility, quota exhaustion, stale requests succeeding later, and retries crossing an idempotency window. The Automatic Retry implementation should bound attempts, preserve the original operation identity, and stop before retries amplify a dependency failure.

A production implementation should classify retryable errors, use exponential backoff with jitter, cap attempts and total duration, honor server guidance, preserve identifiers, and stop retrying after definitive business errors. Metrics for Automatic Retry should separate first-attempt success, recovered operations, exhausted attempts, duplicate prevention, and added latency.

Useful measures include retry rate, success after retry, attempts per operation, retry delay, exhausted retries, duplicate-prevention hits, and downstream load caused by retries. Automatic Retry is closely connected to Exponential Backoff, Idempotent Payment Request, and Circuit Breaker. For Automatic Retry, a missing response should remain uncertain until status lookup or reconciliation confirms whether the original operation executed.

Operational review of Automatic Retry should separate successful recovery from repeated attempts that only increase latency or load. A Automatic Retry decision should use documented method semantics and provider error classes rather than message text alone.

Manual intervention for Automatic Retry should begin only after automated status checks cannot determine a safe final outcome. Configuration changes to Automatic Retry should be versioned and tested under burst, timeout, dependency failure, and restart conditions.