Module retry

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:

• https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/
• https://en.wikipedia.org/wiki/Exponential_backoff
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After

Structs

• Retry
  State for managing retrying a network operation.

Enums

• RetryResult
  The result of attempting some operation via Retry::try.

Constants

• INITIAL_RETRY_JITTER_MS 🔒
  The maximum amount of additional time the initial retry will take (milliseconds).
• INITIAL_RETRY_SLEEP_BASE_MS 🔒
  The minimum initial amount of time a retry will be delayed (milliseconds).
• MAX_RETRY_SLEEP_MS 🔒
  Maximum amount of time a single retry can be delayed (milliseconds).

Functions

• maybe_spurious 🔒
• with_retry
  Wrapper method for network call retry logic.