View Source Tesla.Middleware.Retry (tesla v1.7.0)
Retry using exponential backoff and full jitter.
By defaults, this middleware only retries in the case of connection errors (nxdomain
, connrefused
, etc).
Application error checking for retry can be customized through :should_retry
option.
backoff-algorithm
Backoff algorithm
The backoff algorithm optimizes for tight bounds on completing a request successfully. It does this by first calculating an exponential backoff factor based on the number of retries that have been performed. It then multiplies this factor against the base delay. The total maximum delay is found by taking the minimum of either the calculated delay or the maximum delay specified. This creates an upper bound on the maximum delay we can see.
In order to find the actual delay value we apply additive noise which is proportional to the current desired delay. This ensures that the actual delay is kept within the expected order of magnitude, while still having some randomness, which ensures that our retried requests don't "harmonize" making it harder for the downstream service to heal.
examples
Examples
defmodule MyClient do
use Tesla
plug Tesla.Middleware.Retry,
delay: 500,
max_retries: 10,
max_delay: 4_000,
should_retry: fn
{:ok, %{status: status}} when status in [400, 500] -> true
{:ok, _} -> false
{:error, _} -> true
end
end
options
Options
:delay
- The base delay in milliseconds (positive integer, defaults to 50):max_retries
- maximum number of retries (non-negative integer, defaults to 5):max_delay
- maximum delay in milliseconds (positive integer, defaults to 5000):should_retry
- function to determine if request should be retried:jitter_factor
- additive noise proportionality constant (float between 0 and 1, defaults to 0.2)