Fehler werden nach Ursache und Wirkung klassifiziert
Ein Netzwerk-Timeout, ein Rate Limit, ein abgelaufenes OAuth-Token, ein ungültiges Medium und eine leere optionale Suche verlangen unterschiedliche Reaktionen. Eine gemeinsame Meldung „fehlgeschlagen“ reicht für Reparatur und Nutzerentscheidung nicht aus.
Zusätzlich wird bewertet, ob das Ergebnis sicher unbekannt, eindeutig nicht ausgeführt oder fachlich unbrauchbar ist. Diese Unterscheidung verhindert doppelte externe Aktionen.
- transient: Retry kann sicher sein
- auth: Nutzer oder Reconnect erforderlich
- rate_limit: Backoff und späterer Versuch
- media_invalid: Asset anpassen
- optional_missing: dokumentiert überspringen
- unknown_external_state: zuerst verifizieren
Die Recovery Policy liegt vor dem Fehler fest
Für jede Aktion wird definiert, wie oft sie wiederholt werden darf, welche Fehler retrybar sind, ob ein Providerwechsel zulässig ist und welche Kostenobergrenze gilt. Dadurch entscheidet das System nicht im Ausnahmezustand spontan über neue Risiken.
Ein Fallback muss fachlich gleichwertig und freigegeben sein. Eine Stock-Suche darf von einer Quelle zu einer anderen wechseln, wenn Lizenz, Provenienz und Relevanz geprüft werden. Eine Veröffentlichung darf nicht still über ein anderes Konto oder einen anderen Kanal laufen.
Ein kaputter Einzelkanal bleibt isoliert
Ein Multi-Channel-Job besteht aus unabhängigen Beiträgen mit gemeinsamen Vorstufen. Wenn X eine Berechtigung ablehnt, können Instagram und Pinterest trotzdem bereit sein. Der Gesamtstatus wird dann PARTIAL oder DEGRADED statt SUCCESS oder vollständigem FAILURE.
Gemeinsame Sicherheitsfehler sind anders. Ein falscher Workspace, eine fehlende Gesamtfreigabe oder ein überschrittenes Credit-Limit stoppen alle abhängigen Schritte.
Reparatur muss im Ergebnis sichtbar bleiben
Der Abschluss zählt normale Erfolge, automatisch reparierte Schritte, optionale Überspringungen und Blocker getrennt. Für jede Reparatur bleiben erster Fehler, verwendete Strategie und finales Ergebnis nachvollziehbar.
Diese Transparenz hat praktischen Nutzen: Häufen sich Fallbacks bei einem Provider, ist das ein Betriebsproblem. Wird optionale Musik regelmäßig übersprungen, sollte der Workflow vielleicht standardmäßig ohne Musik planen.
Bekannte Störungen gezielt testen
Self-Healing lässt sich nicht nur durch Happy-Path-Tests belegen. Ein Produktionsgate simuliert mindestens die bekannten Fehlerklassen und prüft, ob Status, Kosten und Folgeaktionen stimmen.
- 429 mit Retry-After
- leere Stock-Suche mit qualifiziertem Fallback
- kein geeignetes optionales Musikstück
- fehlendes Pflichtmedium für einen Kanal
- einzelner Provider degraded
- OAuth-Reconnect erforderlich
- unklarer externer Publishing-Status ohne Doppelversuch
FAQ
Ist ein automatisch reparierter Lauf SUCCESS?
Er kann fachlich abgeschlossen sein, sollte die Reparatur aber separat ausweisen. Ein neutraler Endstatus mit sichtbarer Recovery ist ehrlicher als ein undifferenziertes Grün.
Wann ist ein Provider-Fallback sicher?
Wenn die Aktion wiederholbar, das externe Ergebnis eindeutig nicht ausgeführt, der Ersatz freigegeben und fachlich sowie rechtlich qualifiziert ist.