Classify every status: who is at fault, and retry or not
The responses are scripted. The lab below shows real headers. The 400 line uses the kind of error a bad temperature value produces.
When a call fails, the HTTP status says whose problem it is: 4xx usually means your request needs fixing, 429 means slow down, 5xx means the provider is struggling. Classify every error so code retries only what can succeed and fails loudly on the rest.
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 is_retryable(status) returning True for 408, 429 and 500 to 599, and False otherwise. Test it on 200, 400, 401, 429 and 503.
Write wait_seconds(headers, attempt) that returns the integer in the retry-after header when present, otherwise 2 ** attempt (attempt starts at 0).
Explain it without notes
Which status codes would you retry, and which would you never retry? Why?
How should code react to a 429?
Why not parse an error body as JSON without checking?
Expected output
400 you retry=no wait=- | fix the request | temperature must be between 0 and 2
401 you retry=no wait=- | check the API key | Invalid API key
404 you retry=no wait=- | check the model name and URL | The model does not exist
429 limit retry=yes wait=7s | wait, then retry | Rate limit reached for requests
503 provider retry=yes wait=- | retry with backoff | The server is overloaded
502 provider retry=yes wait=- | retry with backoff | (no JSON error) <html>502 Bad Gatewa
418 unknown retry=no wait=- | log it and fail | I am a teapot