Wiederholungsstrategie & Fehlerbehandlung

Jede Automatisierung sieht an einem guten Tag klug aus. Der echte Test ist, was sie an einem schlechten Tag macht.

Genau dort verdient sich eine Wiederholungsstrategie ihren Platz. Nicht als magischer „noch mal versuchen“-Knopf, sondern als Regelwerk dafür, wann OpenClaw warten, erneut versuchen, die Spur wechseln oder lieber stoppen sollte, bevor es Schaden anrichtet.

Die offizielle Retry-Doku von OpenClaw hält den Kern angenehm schlicht: Wiederhole pro HTTP-Request, nicht pro mehrstufigem Workflow. Dieser eine Satz bewahrt viele vor einem klassischen Fehler, nämlich einen ganzen Ablauf neu zu starten, nur weil ein Request gegen Ende Pech hatte.

Wofür eine Wiederholungsstrategie wirklich da ist

Eine Wiederholungsstrategie ist dafür da, vorübergehende Fehler abzufangen, ohne so zu tun, als wären alle Fehler vorübergehend.

Denk daran wie an die Federung eines Autos. Sie ist da, um Schlaglöcher abzufedern, nicht um das Fahren in eine Wand zu einer brauchbaren Idee zu machen. Timeouts, Rate Limits und kurze Transportprobleme sind Schlaglöcher. Falscher Input, kaputte Berechtigungen oder ein fehlerhafter Request sind die Wand.

Dieser Unterschied zählt, weil Retries nicht kostenlos sind. Jeder Retry kostet Zeit, erzeugt Last und erhöht das Risiko doppelter Seiteneffekte, wenn du das Falsche an der falschen Stelle wiederholst.

Was wiederholt werden sollte, und was besser sofort scheitert

Die aktuellen OpenClaw-Docs zeigen ein klares Muster.

Gute Kandidaten für Retries

• HTTP-429-Rate-Limits, wenn der Provider dich zum Warten auffordert
• Timeouts und kurzlebige Netzwerkfehler
• HTTP-5xx-Antworten von instabilen Upstream-Diensten
• Vorübergehende Transportprobleme wie Connection Resets oder Fetch-Fehler

Für Modell-Provider sagen die Docs, dass OpenClaw normale kurze Retries den Provider-SDKs überlässt. Für Discord und Telegram deckt die Retry-Ebene explizit vorübergehende Fehler ab und nutzt nach Möglichkeit providerspezifische retry_after-Werte.

Kandidaten für schnelles Scheitern

• Fehlerhafte Requests, die unverändert immer wieder scheitern würden
• Berechtigungs- oder Auth-Probleme, die Eingriffe eines Operators brauchen
• Parse- oder Formatierungsfehler, die deterministisch sind
• Nicht-idempotente Seiteneffekte, die blind zu duplizieren riskant wäre

Die Telegram-Doku nennt ein gutes Beispiel ausdrücklich: Markdown-Parse-Fehler werden nicht wiederholt. Sie fallen auf Plain Text zurück. Genau so sollte es sein. Nicht denselben kaputten Payload hämmern und hoffen, dass das Universum plötzlich nachsichtiger wird.

Wo Retries hingehören

Hier geraten viele Automatisierungen leise aus der Spur.

Die offiziellen Docs sagen, dass Retries pro Request gelten, etwa beim Senden einer Nachricht, beim Medien-Upload, bei Reaktionen, Polls oder Stickern. Zusammengesetzte Flows wiederholen keine bereits abgeschlossenen Schritte. Übersetzt heißt das: OpenClaw versucht, den fehlgeschlagenen Request zu retten, nicht die ganze Geschichte zurückzuspulen.

Genau das ist die richtige Grenze, weil Fehlerbehandlung die Reihenfolge wahren und doppelte Arbeit vermeiden soll. Wenn Schritt vier scheitert, lautet die Antwort meist „Schritt vier retten“, nicht „so tun, als wären Schritt eins bis drei nie passiert“.

Eine brauchbare Faustregel:

• Provider-Ebene: kurze Retries für vorübergehende Request-Fehler
• Workflow-Ebene: verzweigen, benachrichtigen oder eskalieren, wenn der Request trotzdem scheitert
• Operator-Ebene: prüfen, auditieren und entscheiden, ob manuelle Wiederherstellung sicherer ist

Standard-Cooldown-Muster in den aktuellen Docs

OpenClaw behandelt nicht jeden Retry als sofortigen Spam. Die aktuelle Retry-Seite nennt diese Defaults:

• Versuche: 3
• Maximales Delay-Cap: 30.000 ms
• Jitter: 10 Prozent
• Telegram-Mindestabstand: 400 ms
• Discord-Mindestabstand: 500 ms

Diese Kombination ist wichtig. Ein Cap verhindert endloses Warten, und Jitter sorgt dafür, dass nicht viele Clients im Gleichschritt neu an dieselbe verriegelte Tür klopfen.

Auf der Modellseite gibt es noch eine schärfere Regel. Für Stainless-basierte SDKs wie Anthropic und OpenAI sagen die Docs: Wenn ein Retry-After-Wert länger als 60 Sekunden ist, injiziert OpenClaw x-should-retry: false, damit das SDK den Fehler sofort meldet und die Modell-Ausfallsicherung übernehmen kann. Das ist eine starke Designentscheidung: nicht ewig bei einem Provider schlafen, wenn ein anderer Weg schneller wieder auf die Beine hilft.

Fehlerbehandlung ist größer als Retries

Eine echte Wiederherstellungsstrategie sagt nicht nur „versuche es drei Mal“. Sie legt auch fest, was nach ausgeschöpften Retries passiert.

Genau hier hilft das Background-Task-Modell. Task-Datensätze in OpenClaw durchlaufen Status wie queued, running, succeeded, failed, timed_out, cancelled und lost. Losgelöste Arbeit kann also sichtbar scheitern, statt einfach im Log-Nebel zu verschwinden.

Die Docs betonen außerdem einen push-basierten Abschluss. Losgelöste Arbeit sollte direkt benachrichtigen oder die anfragende Session wecken, wenn sie fertig ist. Das gesunde Muster sieht also meist so aus:

1. den aktuellen Request erneut versuchen, wenn der Fehler vorübergehend wirkt
2. den finalen Task-Status ehrlich abschließen, wenn die Wiederherstellung trotzdem scheitert
3. das Ergebnis in den richtigen Chat, die richtige Session oder an den richtigen Operator liefern

Das ist deutlich besser als nervöse Polling-Loops und deutlich besser als stilles Scheitern.

Typische Fehler bei der Wiederherstellung

Den ganzen Flow wiederholen statt des kaputten Requests

So entstehen Duplikate. Eine Nachricht wird doppelt gepostet. Eine Datei erneut hochgeladen. Ein langer Ablauf wiederholt, nur weil ein Endpoint kurz vor Schluss gehustet hat. OpenClaws Request-fokussiertes Retry-Modell existiert genau, um das zu verhindern.

Idempotenz ignorieren

Wenn ein Schritt Seiteneffekte hat, frag dich, ob das Wiederholen sicher ist. Ein Health Check ist meist sicher. Ein Kauf, ein Publish-Schritt oder ein Benachrichtigungs-Burst vielleicht nicht.

Zu lange in der falschen Ebene schlafen

Wenn ein Provider dir sagt, du sollst lange warten, kann das ein Signal für Failover sein, nicht nur für Geduld. Die Docs zur Modell-Ausfallsicherung machen das bei langen Retry-After-Werten ausdrücklich klar.

Fehler hinter „Best Effort“ verstecken

Best Effort ist okay für optionale Nice-to-have-Aktionen. Es ist schrecklich, wenn dadurch so getan wird, als wäre ein kritischer Pfad erfolgreich gewesen, obwohl er es nicht war. Ein fehlgeschlagener Publish muss wie ein Fehler aussehen. Eine kaputte Zustellung muss klar sichtbar sein. Operatoren brauchen Wahrheit, keine gute Stimmung.

Ein praktisches Konfigurationsbeispiel

Die Retry-Doku zeigt Richtlinien pro Provider in ~/.openclaw/openclaw.json:

{
  channels: {
    telegram: {
      retry: {
        attempts: 3,
        minDelayMs: 400,
        maxDelayMs: 30000,
        jitter: 0.1,
      },
    },
    discord: {
      retry: {
        attempts: 3,
        minDelayMs: 500,
        maxDelayMs: 30000,
        jitter: 0.1,
      },
    },
  },
}

Der interessante Teil ist nicht die Syntax. Es ist die Absicht dahinter. Halte Retries nah an der Request-Oberfläche, die den Fehlertyp wirklich kennt, und halte die Workflow-Wiederherstellung darüber ehrlich.

Wie du ruhigere Automatisierungen baust

• Wiederhole vorübergehende Request-Fehler, nicht ganze Geschichten
• Scheitere schnell bei fehlerhaften Inputs, Berechtigungen und deterministischen Formatierungsfehlern
• Respektiere Retry-Hinweise des Providers und nutze Jitter
• Nutze Failover, wenn langes Warten schlechter ist als ein Spurwechsel
• Halte finale Task-Ergebnisse fest, damit Menschen später die Realität prüfen können
• Melde Fehler klar, statt sie hinter stillen Retries zu verstecken

Die meisten fragilen Automatisierungen sind nicht kaputt, weil die API einmal einen schlechten Moment hatte. Sie sind kaputt, weil vorher niemand entschieden hat, welche Art von Fehler überhaupt vorliegt.

Die praktische Quintessenz

Nutze Retries für Turbulenzen, nicht für Verdrängung. Platziere sie auf der Request-Ebene, begrenze sie, gib ihnen Jitter und halte sie von bereits erledigten Workflow-Schritten fern. Danach machst du Fehlerbehandlung mit Failover, Task-Status und ehrlicher Meldung explizit.

Das ist nicht glamourös. Es ist einfach die Art, wie verlässliche Systeme vermeiden, zu teuren Spielautomaten zu werden.