Stop bij de verzoeklimiet

Een 429-antwoord zegt “stop voorlopig”. Het vertelt dit kleine commando niet dat het het antwoord achter herhaalde pogingen moet verbergen.

Implementeer inspect_rate_limit(attempt, *, timeout=DEFAULT_TIMEOUT, session=None) als precies één GET naar /scenarios/rate-limit, met params={"attempt": attempt}, de vaste header en de expliciete time-out.

Onderzoek status 429 vóór de algemene statuscontrole. Decodeer de inhoud van dat ene foutantwoord en eis error.code == "practice_rate_limited". Eis dat Retry-After een niet-lege string met decimale cijfers is, zet die om in een geheel getal en geef precies dit terug:

{
    "status": 429,
    "retry_after": retry_after,
    "code": "practice_rate_limited",
}

Roep voor een antwoord dat geen 429 is raise_for_status() vóór json() aan en geef het gedecodeerde succesdocument terug. Elke andere onsuccesvolle status werpt een exceptie op. Vang niets op.

Pogingen 1 en 2 geven deterministische 200-antwoorden. Pogingen 3 tot en met 10 geven deterministische 429-antwoorden met Retry-After: 1. De server is toestandloos: de querywaarde voor de poging kiest het antwoord. Voeg geen lus, sleep, retry-adapter, veranderbare teller of melding toe die beweert dat een latere poging slaagde.

Let op wat deze functie niet doet. Ze slaapt niet, gebruikt geen lus en probeert niet opnieuw. Ze leest het stopsignaal, verpakt het en geeft het terug aan degene die erom vroeg. Beslissen of je een seconde wacht en opnieuw probeert is beleid. Dat hoort bij de aanroeper die weet waarvoor het programma dient.