← Exercises|

Repair: the API that lies about the total

Repair19 of 26 · about 10 min

Repair: the API that lies about the total

Northstar's case API pages at 50 and reports a total on page 1 that is computed BEFORE the account filter is applied. A client that stops when it has collected total records stops in the wrong place — sometimes early, sometimes never.

It also has two failure modes that do not look like failures. About one call in fifty returns **200 with an empty body**, and it rate-limits at an undocumented threshold with a **429 and no Retry-After**. response.ok is true for the first and the second needs a backoff you have to choose yourself.

Walk until the server says there is no more. Treat an empty body as a retryable failure, not as the end of the data — those two are indistinguishable to a loop that only checks for an empty list.

Example

# Wrong: trusts a number the vendor computes before filtering
while len(collected) < body["total"]:
    ...

# Right: walks until the server stops saying there is more
while has_more:
    ...

Your task

The recorded responses are in pages.json, in the order the server returned them. Fix fetch_all so it collects every case exactly once, retries an empty body and a 429, and prints the ids it collected followed by the retry count.

Stuck?

Explain it

Real retries need a delay. With no Retry-After header, how would you choose one, and what stops the loop forever?

Not graded — this is for you.

Where this goes

D3 integrates with this API for real. Its rubric asks you to demonstrate the empty-body case specifically, because it is the one most adapters never handle.