Expand description
Utilities for retrying a network operation.
Some network errors are considered “spurious”, meaning it is not a real
error (such as a 404 not found) and is likely a transient error (like a
bad network connection) that we can hope will resolve itself shortly. The
Retry
type offers a way to repeatedly perform some kind of network
operation with a delay if it detects one of these possibly transient
errors.
This supports errors from git2
, [gix
], curl
, and
HttpNotSuccessful
5xx HTTP errors.
The number of retries can be configured by the user via the net.retry
config option. This indicates the number of times to retry the operation
(default 3 times for a total of 4 attempts).
There are hard-coded constants that indicate how long to sleep between retries. The constants are tuned to balance a few factors, such as the responsiveness to the user (we don’t want cargo to hang for too long retrying things), and accommodating things like Cloudfront’s default negative TTL of 10 seconds (if Cloudfront gets a 5xx error for whatever reason it won’t try to fetch again for 10 seconds).
The timeout also implements a primitive form of random jitter. This is so that if multiple requests fail at the same time that they don’t all flood the server at the same time when they are retried. This jitter still has some clumping behavior, but should be good enough.
Retry
is the core type for implementing retry logic. The
Retry::try
method can be called with a callback, and it will
indicate if it needs to be called again sometime in the future if there
was a possibly transient error. The caller is responsible for sleeping the
appropriate amount of time and then calling Retry::try
again.
with_retry
is a convenience function that will create a Retry
and
handle repeatedly running a callback until it succeeds, or it runs out of
retries.
Some interesting resources about retries:
Structs
- State for managing retrying a network operation.
Enums
- The result of attempting some operation via
Retry::try
.
Constants
- The maximum amount of additional time the initial retry will take (milliseconds).
- The minimum initial amount of time a retry will be delayed (milliseconds).
- Maximum amount of time a single retry can be delayed (milliseconds).
Functions
- Wrapper method for network call retry logic.