retry logic

**Retry logic** is a software pattern that **automatically re-attempts** a failed operation with the expectation that transient failures (network glitches, rate limits, temporary server overload) will resolve on subsequent attempts. It is essential for building reliable AI applications that interact with external APIs. **Why Retry Logic is Critical for LLM Applications** - **API Rate Limits**: LLM providers return **HTTP 429** when usage limits are exceeded — retrying after a delay is the expected behavior. - **Transient Failures**: Cloud services experience brief outages, network timeouts, and load spikes that resolve within seconds. - **Server-Side Throttling**: During peak demand, providers may temporarily reject requests to maintain overall system stability. **Retry Strategies** - **Fixed Delay**: Wait a constant time between retries (e.g., retry every 2 seconds). Simple but can cause thundering herd problems. - **Exponential Backoff**: Double the wait time after each failure (1s → 2s → 4s → 8s). The standard approach for API retry logic. - **Exponential Backoff with Jitter**: Add random jitter to the backoff delay to prevent multiple clients from retrying at the exact same time. **Recommended for production use**. - **Linear Backoff**: Increase wait time linearly (1s → 2s → 3s → 4s). A middle ground between fixed and exponential. **Key Parameters** - **Max Retries**: Maximum number of attempts before giving up (typically 3–5 for API calls). - **Initial Delay**: Time before the first retry (typically 0.5–2 seconds). - **Max Delay**: Cap on the backoff time to prevent excessively long waits (typically 30–60 seconds). - **Retryable Errors**: Only retry on transient errors (429, 500, 502, 503, timeout) — never retry on client errors like 400 or 401. **Implementation Best Practices** - **Idempotency**: Ensure the operation is safe to retry — retrying a non-idempotent operation (like creating a record) can cause duplicates. - **Circuit Breaker**: After too many failures, stop retrying and fail fast to avoid wasting resources on a clearly broken service. - **Logging**: Log each retry attempt with the error reason and delay for debugging. - **Respect Retry-After Headers**: When the server provides a Retry-After header, use that delay instead of your own backoff. Retry logic is a **fundamental reliability pattern** — every production AI application calling external APIs should implement exponential backoff with jitter.