promptdojo_

when the pipeline breaks — error bodies, retries, and backoff — step 8 of 8

ch 04 · read the pipeline8/8

Going deeper — the one pattern to keep

The editor on the right is this chapter folded into one function. fetch_with_backoff has every seatbelt from the last three lessons: attempts are bounded (max_attempts), success returns immediately, 429 honors the Retry-After header, 5xx backs off with a doubling wait, and every other 4xx goes straight to raise_for_status() — no retry, because re-sending a broken request never fixes it.

Run it. The fake queue serves a 429, then a 503, then a 200 — watch the function wait, back off, and finally hand you the body. The time.sleep(0) line is where real code sleeps for wait seconds; we skip the actual waiting so the demo is instant.

Use your AI assistant as a reference — then verify by running

This function is deliberately paste-able. When you're building something real and a call starts failing, paste the pattern (or the failing code) into your AI assistant with a targeted question:

Here's my retry helper. My API returns 429 with a Retry-After
header measured in milliseconds, not seconds. What exactly do I
change, and what should I log on each attempt so I can see the
backoff working?

The answer will usually be good — and occasionally, confidently wrong. The discipline that makes the difference: run the answer before you trust it. Every claim about this pattern is checkable in the editor in under a minute. Change the queue to three 503s and confirm it gives up after max_attempts. Feed it a 401 and confirm it raises instead of retrying. If the assistant's version behaves differently from what it claimed, you just caught the bug before production did — that run-it habit is the whole skill this course is building.

Where to look things up

The primary sources, when you want the full story instead of an answer-shaped answer:

  • docs.python.org/3/library/ — the standard library reference. pathlib, json, hashlib, and time from this chapter each have a page there, with every method signature.
  • docs.python.org/3/tutorial/errors.html — the official tutorial chapter on exceptions, which is what raise_for_status and your try/except blocks are built on.
  • Your HTTP client's own docs — httpx documents timeouts, status handling, and HTTPStatusError precisely; read its quickstart once and the four-line call shape will never surprise you again.

A good loop: ask the assistant for the shape, check the docs for the contract, and run the code for the truth. Next chapter, the URL points at an LLM provider, the body grows a messages list — and this exact retry pattern comes along unchanged.

read, then continue.