Loading challenge...
Exponential-Backoff Retry
Retry a flaky endpoint with growing delays until it succeeds, and assert the give-up branch too
What you will learn
- Implement an exponential-backoff retry loop against a transiently failing endpoint with a capped give-up
- Use data-* state attributes (data-outcome, data-count) as deterministic sync points instead of fixed sleeps
- Inject deterministic failures with route.fulfill + a call counter to test both success-after-retry and terminal failure
Exponential-Backoff Retry — Survive a Flaky Endpoint
The server fails the first two calls and only succeeds on the third — your client must retry with growing delays until it gets a 200 or gives up
Clicking start issues a POST /api/lab/flaky to mint a token, then polls GET /api/lab/flaky?token=… in a loop. The endpoint returns 500 on calls 1 and 2 and 200 from call 3 onward.
Each retry waits longer than the last (exponential backoff: 300, 600, 1200 ms…), capped at 5 attempts before the client declares a terminal failure.
Run the Retry Loop
Watch the attempts climb until success
Attempt: 0 / 5
Idle — press start to begin
Testing Tips
Automation hints
- ✓ Click
#retry-start, then poll the#retry-result[data-outcome]attribute — it transitionspending → successonly after the loop reaches a 200 - ✓ The backoff schedule (300+600+1200 ms) means success lands ~2 s in — wait for the attribute, do not assert immediately after the click
- ✓
#attempt-count(and itsdata-count) climbs each try — assert it reached at least 3, proving the client actually retried rather than passing first-shot - ✓ In Playwright,
route.fulfillwith a call counter (fail calls 1-2, succeed on 3) is the canonical way to inject deterministic flakiness for your own retry tests - ✓ Also cover the terminal give-up path: stub the endpoint to fail every call and assert
#retry-result[data-outcome=failed]after the cap
