RequestInterceptors Enumeration Reference
public enum RequestInterceptorsFactories for the built-in RequestInterceptors that add retry behavior to a NetworkClient.
Pass the created interceptors to NetworkClient.newClient(withAdditionalInterceptors:maxRetryCount:). Interceptors
are consulted in reverse order, so add retryWhenConnected(connectivityManager:) last: it is then asked first and,
while the connection is assumed unavailable, waits for it instead of letting retryWithBackoff(...) use up its attempts:
let client = context.network.networkClient.newClient(withAdditionalInterceptors: [
RequestInterceptors.retryWithBackoff(maxAttempts: 3),
RequestInterceptors.retryWhenConnected(connectivityManager: context.network.connectivityManager)
], maxRetryCount: 10)
-
Creates a
RequestInterceptorthat makes a retryable failure wait for the SDK’s connectivity signal while the connection is assumed unavailable.For a retryable error while
ConnectivityManagerProtocol.connectionAssumedAvailableisfalse, the interceptor retries the next timeconnectionAssumedAvailablebecomestrue. Otherwise it expresses no opinion, so another interceptor may still retry.Declaration
Swift
static func retryWhenConnected(connectivityManager: ConnectivityManagerProtocol) -> RequestInterceptorParameter Description connectivityManagerthe connectivity manager used to know when connectivity is assumed available again.
Return Value
a new
RequestInterceptor; it can be shared between clients. -
retryWithBackoff(maxAttempts:transientBaseDelay: throttlingBaseDelay: maxDelay: retryAfterAboveMaxDelay: ) Creates a
RequestInterceptorthat retries retryable failures with a full-jitter exponential backoff, and decides when to give up.- A failure is retryable when its
NetworkErrorType.isRetryableistrue, for example HTTP 429 and 503, or a lost connection. - 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).baseisthrottlingBaseDelayfor HTTP 429 andtransientBaseDelayotherwise. - 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 abovemaxDelay, the interceptor either stops proposing a retry or waits for it in full, depending onretryAfterAboveMaxDelay. maxAttemptscounts 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 amaxRetryCount.
Declaration
Swift
static func retryWithBackoff(maxAttempts: Int? = 3, transientBaseDelay: TimeInterval = 0.1, throttlingBaseDelay: TimeInterval = 1, maxDelay: TimeInterval = 20, retryAfterAboveMaxDelay: RetryAfterAboveMaxDelay = .giveUp) -> RequestInterceptorParameter Description maxAttemptsthe maximum number of consecutive attempts, including the initial one.
nilmeans there is no cap.transientBaseDelaythe base delay, in seconds, for retryable failures other than HTTP 429.
throttlingBaseDelaythe base delay, in seconds, for HTTP 429 responses.
maxDelaythe longest backoff delay, in seconds. A
Retry-Afterup to this long is waited as a minimum; a longer one is handled perretryAfterAboveMaxDelay.retryAfterAboveMaxDelaywhat to do when a
Retry-Afterheader asks for longer thanmaxDelay:.giveUpstops proposing a retry, so another interceptor may still retry, and.waitwaits for the full header, with no upper bound.Return Value
a new
RequestInterceptor; it keeps no state, so it can be shared between clients. - A failure is retryable when its