Retry Policy
The rulebook for when a failed call gets another try, how long each wait lasts, and when the caller finally gives up.
See it
What it is
A retry policy decides which failures deserve another attempt, how long to wait, and when to give up. For HTTP calls, timeouts, 429, and temporary 502, 503, or 504 responses are common retry candidates. A bad request or invalid credential usually needs a fix, not another identical call.
Use exponential backoff plus jitter so many clients do not retry in lockstep. The AWS Architecture Blog post 'Exponential Backoff And Jitter' is what put full jitter in most SDK defaults. Honor Retry-After when the server sends it, cap both the attempt count and total elapsed time, and log the final failure with enough context to replay or investigate it.
Retries multiply side effects unless the operation is idempotent. GET is normally safe to repeat; creating a charge or order may not be unless the API accepts an idempotency key. A timeout is especially tricky because the server may have completed the work after your client stopped waiting.
Ask AI for it
Wrap this HTTP client in a retry policy built with p-retry, retrying network errors, 408, 429, 502, 503, and 504, but not other 4xx responses. Honor the Retry-After header; otherwise use full-jitter exponential backoff starting at 250 ms and capped at 8 seconds. Stop after 5 attempts or a 30-second total deadline, whichever comes first. Retry POST only when an idempotency key is present, expose attempt metrics, and test timeout, 429, recovery, and exhaustion paths.