Zuerst klären, welcher Fehler vorliegt
HTTP 429 bedeutet, dass ein Anbieter in diesem Moment keine weitere Anfrage akzeptiert. Das ist anders als ein abgelaufenes OAuth-Token, fehlende Berechtigung, ungültiges Medium oder ein fachlicher Plattformfehler. Nur korrekt klassifizierte Fehler erhalten die passende Reparatur.
Die Antwort kann einen Retry-After-Hinweis enthalten. Fehlt er, verwendet das System einen begrenzten exponentiellen Backoff mit zufälliger Streuung. Dadurch starten parallele Jobs nicht gleichzeitig erneut und erzeugen sofort das nächste Limit.
Vor dem Retry muss Idempotenz geklärt sein
Bei einem Verbindungsabbruch ist nicht immer bekannt, ob der Provider den Beitrag bereits angenommen hat. Ein blindes Retry kann dann doppelt veröffentlichen. Jeder Publishing-Job braucht eine stabile interne ID und – wenn unterstützt – einen Idempotency Key oder eine Provider-Referenz.
Ist das Ergebnis unklar, wechselt der Job in einen Zustand wie UNKNOWN oder VERIFYING. Das System prüft zuerst Providerstatus und vorhandene Referenzen. Erst ein eindeutig nicht ausgeführter Versuch darf wiederholt werden.
Backoff bleibt begrenzt und beobachtbar
Ein sinnvoller Retry-Plan hat eine maximale Versuchszahl, eine maximale Wartezeit und ein Ende. Jeder Versuch protokolliert Fehlerklasse, Zeitpunkt und nächsten Termin. Endlose Wiederholungen verschleiern einen Defekt und können weitere Kosten verursachen.
Nach ausgeschöpften Versuchen wird der Beitrag nicht als Erfolg markiert. Er bleibt blockiert oder wird zur Nutzeraktion eskaliert. Andere Plattformen dürfen weiterlaufen, sofern ihre Jobs unabhängig sind.
- Retry-After respektieren
- exponentiellen Backoff mit Jitter verwenden
- maximale Versuche begrenzen
- keine Wiederholung bei unklarem externem Ergebnis
- pro Plattform isolieren
- Reparatur im Abschluss sichtbar machen
Provider-Fallback ist nicht immer möglich
Bei Stock-Medien oder generativer Verarbeitung kann ein anderer freigegebener Provider denselben fachlichen Zweck erfüllen. Beim eigentlichen Social Publishing ist das Zielkonto jedoch an eine Plattformverbindung gebunden. Ein Wechsel darf nicht unbemerkt über ein anderes Konto oder Tool veröffentlichen.
Der Fallback wird deshalb nach Aktionstyp bewertet. Eine leere Bildsuche kann auf eine zweite qualifizierte Quelle wechseln. Ein fehlendes OAuth-Recht verlangt eine erneute Verbindung. Ein ungültiges Seitenverhältnis verlangt eine Medienanpassung.
Kurzes Runbook für den Betrieb
Ein Team sollte für wiederkehrende Publishing-Fehler einen festen Ablauf besitzen. Er reduziert spontane Reparaturen und macht Statusmeldungen verständlich.
- Fehlerklasse und betroffenen Kanal anzeigen
- externen Status und Provider-ID prüfen
- sicheren Retry oder konkrete Nutzeraktion bestimmen
- unabhängige Jobs fortsetzen
- nach Abschluss Queue und Kalender abgleichen
- Duplikate über interne und externe IDs ausschließen
FAQ
Soll ein 429 sofort wiederholt werden?
Nein. Der Providerhinweis oder ein begrenzter Backoff sollte abgewartet werden. Sofortige parallele Retries verschärfen das Limit häufig.
Darf der Gesamtjob wegen einer Plattform stoppen?
Nur wenn eine gemeinsame sicherheitsrelevante Voraussetzung fehlt. Ein isolierter Plattformfehler sollte andere unabhängige Beiträge nicht blockieren.