Am Anfragelimit anhalten

Eine 429-Antwort sagt: „Hör vorerst auf.“ Sie weist diesen kleinen Befehl nicht an, die Antwort hinter Wiederholungsversuchen zu verstecken.

Implementiere inspect_rate_limit(attempt, *, timeout=DEFAULT_TIMEOUT, session=None) als genau eine GET-Anfrage an /scenarios/rate-limit, mit params={"attempt": attempt}, dem festen Header und dem ausdrücklichen Timeout.

Prüfe Status 429 vor der allgemeinen Statusprüfung. Dekodiere diesen einen Fehlerinhalt und verlange error.code == "practice_rate_limited". Verlange, dass Retry-After ein nicht leerer String aus Dezimalziffern ist, wandle ihn in eine ganze Zahl um und gib genau Folgendes zurück:

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

Bei einer Antwort ohne 429 rufst du raise_for_status() vor json() auf und gibst das dekodierte Erfolgsdokument zurück. Jeder andere erfolglose Status löst eine Ausnahme aus. Fange nichts ab.

Die Versuche 1 und 2 ergeben deterministische 200-Antworten. Die Versuche 3 bis 10 ergeben deterministische 429-Antworten mit Retry-After: 1. Der Server ist zustandslos: Der Abfragewert für den Versuch wählt die Antwort aus. Ergänze weder Schleife noch sleep, Retry-Adapter, veränderlichen Zähler oder eine Meldung, die behauptet, ein späterer Versuch sei erfolgreich gewesen.

Achte darauf, was diese Funktion nicht tut. Sie schläft nicht, läuft nicht in einer Schleife und versucht es nicht erneut. Sie liest das Stoppsignal, verpackt es und gibt es an den Aufrufer zurück. Ob eine Sekunde gewartet und erneut versucht werden soll, ist eine Strategieentscheidung. Sie gehört zum Aufrufer, der den Zweck des Programms kennt.