retryWithBackoff
Creates an interceptor that retries retryable failures (see NetworkException.isRetryable), for example HTTP 429 and 503 or a lost connection, with a full-jitter exponential backoff, and decides when to give up.
The
n-th retry in a row proposed by this interceptor, counting from 0, waits a random delay between 0 andmin(maxDelay, base * 2^n).baseis throttlingBaseDelay for HTTP 429 and transientBaseDelay otherwise.A
Retry-Afterheader is a minimum wait: the delay is the larger of the header and the backoff. The header can be a number of seconds or an HTTP date in the IMF-fixdate format, measured against the response'sDateheader when present so a skewed device clock doesn't matter. Other formats are ignored. For a header above maxDelay, the interceptor either stops proposing a retry or waits for it in full, depending on retryAfterAboveMaxDelay.maxAttempts counts consecutive attempts, including the one that just failed. The count, and with it the backoff, restarts when another interceptor proposed the last retry, for example after waiting for connectivity. To limit the total retries of a request, derive the client with a
maxRetryCount(see NetworkClient.newClient).
Return
A new RequestInterceptor; it keeps no state, so it can be shared between clients.
Parameters
The maximum number of consecutive attempts, including the initial one; null means there is no cap.
The base delay for retryable failures other than HTTP 429.
The base delay for HTTP 429 responses.
The longest backoff delay. A Retry-After up to this long is waited as a minimum; a longer one is handled per retryAfterAboveMaxDelay.
What to do when a Retry-After header asks for longer than maxDelay: RetryAfterAboveMaxDelay.GIVE_UP stops proposing a retry, so another interceptor may still retry, and RetryAfterAboveMaxDelay.WAIT waits for the full header, with no upper bound.