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 transitions pending → success only 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 its data-count) climbs each try — assert it reached at least 3, proving the client actually retried rather than passing first-shot
✓ In Playwright, route.fulfill with 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

Related Challenges

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.

Testing Tips

Automation hints

✓ Click #retry-start, then poll the #retry-result[data-outcome] attribute — it transitions pending → success only 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 its data-count) climbs each try — assert it reached at least 3, proving the client actually retried rather than passing first-shot
✓ In Playwright, route.fulfill with 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

Exponential-Backoff Retry

What you will learn

Exponential-Backoff Retry — Survive a Flaky Endpoint

Run the Retry Loop

Testing Tips

Timer

Need Help?

Related Challenges

Dynamic Content

Dynamic Loading

Dynamic Controls

Exponential-Backoff Retry

What you will learn

Exponential-Backoff Retry — Survive a Flaky Endpoint

Run the Retry Loop

Testing Tips

Timer

Need Help?

Related Challenges

Dynamic Content

Dynamic Loading

Dynamic Controls