Ziele
- Wiederholungsversuche erfolgen pro HTTP-Anfrage, nicht pro mehrstufigem Ablauf.
- Die Reihenfolge bleibt erhalten, da nur der aktuelle Schritt wiederholt wird.
- Die Duplizierung nicht idempotenter Vorgänge wird vermieden.
Standardwerte
Verhalten
Modell-Provider
- OpenClaw überlässt den Provider-SDKs die üblichen kurzen Wiederholungsversuche.
- Bei Stainless-basierten SDKs wie Anthropic und OpenAI können wiederholbare Antworten (
408,409,429und5xx)retry-after-msoderretry-afterenthalten. Wenn diese Wartezeit länger als 60 Sekunden ist, fügt OpenClawx-should-retry: falseein, damit das SDK den Fehler sofort meldet und das Modell-Failover zu einem anderen Authentifizierungsprofil oder Fallback-Modell wechseln kann. - Überschreiben Sie die Obergrenze mit
OPENCLAW_SDK_RETRY_MAX_WAIT_SECONDS=<seconds>. Setzen Sie sie auf0,false,off,noneoderdisabled, damit SDKs langeRetry-After-Wartezeiten intern berücksichtigen.
Discord
- Wiederholungsversuche erfolgen bei Rate-Limit-Fehlern (HTTP 429), Anfragezeitüberschreitungen, HTTP-5xx-Antworten und vorübergehenden Transportfehlern wie Fehlern bei der DNS-Auflösung, Verbindungsabbrüchen, Socket-Schließungen und Abruffehlern.
- Verwendet Discord
retry_after, sofern verfügbar, andernfalls exponentielles Backoff.
Telegram
- Wiederholungsversuche erfolgen bei vorübergehenden Fehlern (429, Zeitüberschreitung, Verbindungs-/Zurücksetzungs-/Schließfehler, vorübergehend nicht verfügbar).
- Verwendet
retry_after, sofern verfügbar, andernfalls exponentielles Backoff. - HTML-/Markdown-Analysefehler werden nicht erneut versucht; beim ersten Versuch wird auf Klartext zurückgegriffen.
Konfiguration
Legen Sie die Wiederholungsrichtlinie pro Provider in~/.openclaw/openclaw.json fest:
Hinweise
- Wiederholungsversuche gelten pro Anfrage (Nachrichtenversand, Medien-Upload, Reaktion, Umfrage, Sticker).
- Zusammengesetzte Abläufe wiederholen keine abgeschlossenen Schritte.