How to back off and retry when the service asks you to.
The API documents 429 and 529 with an explicit instruction to retry with exponential backoff, and the official SDKs do so by default; RetryPolicy.default matches their settings.
Everything here is pure. delayFor takes the jitter sample as an argument rather than drawing one, which means the whole schedule is a function of its inputs and can be tested exactly, with no clock, no random source, and no mocking library. Drawing the sample is the client's job.
Value parameters
- backoffInitial
-
the first delay, doubled each attempt
- backoffMax
-
ceiling for the doubling
- jitter
-
0 to 1; the fraction by which a delay may vary, so that many clients retrying at once spread out instead of arriving together
- maxRetries
-
attempts after the first; 0 disables retrying
- respectRetryAfter
-
whether a
Retry-Afterheader wins when it asks for longer than the computed backoff - retryableStatuses
-
which statuses are worth retrying
- totalTimeout
-
ceiling on the whole call, retries included. Exceeding it fails the call with a com.softinio.verdict4s.Verdict4sError.Transport. A delay, from the header or the backoff, of at least the time left in it ends the retries instead, with the server's own error, since that wait could only end in a timeout.
Attributes
- Companion
- object
- Graph
-
- Supertypes