View Source Anthropic.HTTPTransport.Retry (anthropic_community v0.5.0)
Exponential backoff + jitter, shared by both plain requests (HTTPTransport.post/3) and
the initial connection attempt of HTTPTransport.stream/3, so retry behavior never
diverges between the two.
Summary
Functions
Computes the delay in milliseconds before the next attempt. Honors a retry-after-ms
header (preferred, more precise, sanity-bounded to 0 < ms <= 60_000) or retry-after
header (seconds, sanity-bounded to 0 < seconds <= 60) when present; otherwise uses
exponential backoff — 500ms, 1s, 2s, 4s, ... capped at 8s — with up to 25% negative jitter.
Whether attempt number attempt (0-indexed) should be retried. A response-level
x-should-retry: true/false header always wins (matching the API's own override
signal); otherwise falls back to Anthropic.Error.retryable?/1. Always bounded by
max_retries, even when the header says to retry.
Functions
@spec delay_ms(attempt :: non_neg_integer(), headers :: [{String.t(), String.t()}]) :: non_neg_integer()
Computes the delay in milliseconds before the next attempt. Honors a retry-after-ms
header (preferred, more precise, sanity-bounded to 0 < ms <= 60_000) or retry-after
header (seconds, sanity-bounded to 0 < seconds <= 60) when present; otherwise uses
exponential backoff — 500ms, 1s, 2s, 4s, ... capped at 8s — with up to 25% negative jitter.
@spec should_retry?( Anthropic.Error.t(), attempt :: non_neg_integer(), max_retries :: non_neg_integer(), headers :: [{String.t(), String.t()}] ) :: boolean()
Whether attempt number attempt (0-indexed) should be retried. A response-level
x-should-retry: true/false header always wins (matching the API's own override
signal); otherwise falls back to Anthropic.Error.retryable?/1. Always bounded by
max_retries, even when the header says to retry.