BuildMidBackendAuto-graded
Add backoff to a client that hammers upstream
Handling failure well means retrying gently, giving up in time, and never retrying what can never succeed.Your service calls a flaky upstream: it throttles, it 503s, it times out. The current retry wrapper handles that by retrying every exception with no backoff and a broken attempt count — so it hammers the upstream, keeps retrying errors that can never succeed like a 400 or aValueError, and never gives up cleanly. Fix it so retries are bounded, delays grow, and only the errors worth retrying are retried.30 min
python
You're done when
- A call that keeps failing gives up after exactly the configured maximum number of attempts.
- A non-retryable error is not retried, and no backoff sleep is spent on it.
- Delays increase strictly from one attempt to the next.
- That growth is exponential rather than a fixed pause.
What it measures
Resilience engineeringRetrying in a way that helps a struggling upstream recover instead of adding to the load that broke it.
PythonGetting attempt counting and the number of sleeps exactly right, where off-by-one is the usual defect.
Classifying failuresDistinguishing transient errors worth retrying from permanent ones where retrying only wastes time and budget.
Your environment
Terminal + editorA full shell in the browser
Claude CodePre-authenticated, no key setup
Isolated microVMYours alone, wiped afterwards
Start this lab
30 min
Start labYou'll sign in to Anthropos to start. The lab opens in a private cloud workspace with Claude Code ready to use.AI Labs is part of Anthropos Workforce. Not on your plan yet? Book a demo