A retry helper with backoff, jitter and a flaky server
Change Random(7) to Random(8) and see different waits. The sleep is a recorder, so nothing really waits. The * in the function's parameter list means everything after it must be given by name (Topic 5.4). The else: after try runs only when no error happened (Topic 7.1).
Networks and servers fail in short bursts, so a good client retries only the failures that can pass (timeouts, 429, 5xx), waits longer after each try with random jitter, honours the server's Retry-After header, and never repeats a request that is not safe to repeat.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write backoff_delays(attempts, base, cap) that returns the list of backoff ceilings with no randomness. For (5, 0.5, 4.0) it should be [0.5, 1.0, 2.0, 4.0, 4.0].
Write is_retryable(status) that returns True for 429 and any 5xx except 501, False otherwise.
Write a function wait_time(response, backoff) that returns the larger of the backoff and the Retry-After header (in seconds, if present).
Explain it without notes
Which failures should a client retry, and which should it not?
Explain exponential backoff with jitter and why the jitter is needed.
What is Retry-After, and how does a client use it with its own backoff?
What is idempotency, and how does it affect retrying a POST request?
A POST request to create an order times out. What do you do?
Expected output
attempt 1: status 503
waiting 0.16s (ceiling 0.5s)
attempt 2: status 503
waiting 0.15s (ceiling 1.0s)
final: 200 {'answer': 42}
total fake sleeping: 0.31 seconds in 2 waits