HTTP 429: Retry-After verstehen und Wiederholungen sicher begrenzen

Den begrenzenden Dienst ermitteln

Protokolliere Zeitpunkt, Endpunkt, Methode, Status, Anfragekennung und Warte-Header, jedoch keine Zugangsdaten oder personenbezogenen Inhalte. Unterscheide API, Proxy und CDN; das Aussehen einer Fehlerseite beweist ihre Herkunft nicht.

Limits können je IP, Benutzer, Anwendung oder Ressource gelten. Minutenquote, gleichzeitige Anfragen und Tagesquote brauchen unterschiedliche Lösungen. Eine erschöpfte Tagesquote wird durch kurzes Warten nicht erneuert.

• Sind mehr Aufgaben oder mehr Wiederholungen hinzugekommen?
• Teilen andere Dienste, Tabs oder Schlüssel das Konto?
• Werden Anfragen, aktive Vorgänge, Tokens oder andere Ressourcen gezählt?
• Passt der Wiederaufnahmezeitpunkt noch zur Nutzerfrist?

Retry-After in der richtigen Einheit lesen

Der Wert ist eine nichtnegative Ganzzahl in Sekunden oder ein HTTP-Datum. Der Wert 12 bedeutet 12 Sekunden, nicht Millisekunden. Datumswerte brauchen eine zuverlässige Uhr; ein vergangenes Datum rechtfertigt keine enge Wiederholungsschleife.

Beachte die Mindestwartezeit des Servers und ergänze eine zufällige Streuung. Überschreitet sie die Aufgabenfrist, stoppe oder plane neu. Kürze sie nicht auf eine kleinere lokale Obergrenze.

Die gesamte Warteschlange budgetieren

Bei 120 Anfragen pro Minute für das ganze Konto brauchen 600 mindestens fünf Minuten ohne weiteren Verkehr. Alle in zehn Sekunden zu senden und danach zu warten bleibt eine Lastspitze.

Ein Ziel von 90 pro Minute entspricht 1.5 pro Sekunde, ungefähr einem Start alle 667 Millisekunden. Für 600 sind 400 Sekunden nötig, noch ohne Latenz und Wiederholungen. Bei 2 Sekunden Antwortzeit liegen durchschnittlich 1.5 × 2 = 3 Vorgänge gleichzeitig an. Ein Semaphor begrenzt aktive Vorgänge, ein gemeinsamer Taktgeber die Starts. Auch Wiederholungen verbrauchen Budget.

Example workload assumptions:
Account allowance: 120 requests/minute
Operating target: 90 requests/minute = 1.5 requests/second
600 requests / 1.5 requests/second = 400 seconds
Average concurrency at 2 seconds/response: 1.5 × 2 = 3

Wartezeiten mit Zufallsanteil erhöhen

Ohne gültige Vorgabe kann eine Richtlinie das Fenster auf eine, zwei, vier und acht Sekunden vergrößern und die tatsächliche Pause zufällig wählen. Dadurch starten Ausführende nicht gleichzeitig neu.

Die Funktion berechnet nur die Pause. Aufrufende müssen Frist, Versuchslimit, Abbruch und sichere Wiederholung umsetzen. Im Browser muss der Server Retry-After gegebenenfalls über CORS zugänglich machen.

function retryDelayMs(retryAfter, attempt, nowMs = Date.now()) {
  const text = String(retryAfter ?? "").trim();
  if (/^\d+$/.test(text)) {
    const milliseconds = Number(text) * 1000;
    return Number.isSafeInteger(milliseconds) ? milliseconds : Infinity;
  }
  if (/^(Mon|Tue|Wed|Thu|Fri|Sat|Sun), \d{2} (Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec) \d{4} \d{2}:\d{2}:\d{2} GMT$/.test(text)) {
    const dateMs = Date.parse(text);
    if (Number.isFinite(dateMs)) return Math.max(0, dateMs - nowMs);
  }
  const windowMs = Math.min(8000, 1000 * 2 ** attempt);
  return Math.floor(Math.random() * windowMs);
}
// Example policy: at most 4 retries and a 30-second total deadline.
// If the required wait exceeds the remaining deadline, stop.

Doppelte Nebenwirkungen verhindern

Daten zu lesen ist etwas anderes als eine Zahlung anzulegen. Prüfe Idempotenz und mögliche Wirkung des ersten Versuchs. Verwende für denselben logischen Vorgang denselben Schlüssel; neue Schlüssel können Duplikate erzeugen.

Ein SDK wiederholt möglicherweise bereits selbst. Eine äußere Schleife vervielfacht dann Netzwerkanfragen. Begrenze die tatsächlichen Versuche über alle Schichten. Bei Nutzeraktionen ist ein späterer neuer Versuch oft besser als endloses Warten.

• Eine Gesamtfrist setzen und wartende Aufgaben abbrechen.
• Gemeinsame Grenzen für Gleichzeitigkeit und Starts verwenden.
• Antwortressourcen vor der Pause freigeben.
• Bei erschöpfter Quote oder dauerhaftem Fehler stoppen.
• Versuche und Endergebnis protokollieren.

Mit einem kleinen Stapel prüfen

Beginne mit zwanzig Leseanfragen und zähle erste Versuche, Wiederholungen, Erfolge und endgültige Fehler. Prüfe Abstand und aktive Vorgänge. Simuliere 429 und Retry-After, ohne einen echten Dienst zu belasten.

Plane mit den Rechnern für Anfragerate und Gleichzeitigkeit und vergleiche mit dem Anbieterlimit. Bleibt der Fehler, untersuche andere Aufrufende und die Quotenart, bevor du Wartezeiten blind erhöhst.