Retry-Richtlinie

Ziele

• Retry pro HTTP-Request, nicht pro mehrstufigem Flow.
• Reihenfolge bewahren, indem nur der aktuelle Schritt wiederholt wird.
• Doppelte Ausfuehrung nicht-idempotenter Operationen vermeiden.

Standardwerte

• Versuche: 3
• Maximale Verzoegerung: 30000 ms
• Jitter: 0.1 (10 Prozent)
• Provider-Standards:
  • Telegram minimale Verzoegerung: 400 ms
  • Discord minimale Verzoegerung: 500 ms

Verhalten

Discord

• Retry nur bei Rate-Limit-Fehlern (HTTP 429).
• Nutzt Discords retry_after, falls verfuegbar, ansonsten exponentiellen Backoff.

Telegram

• Retry bei transienten Fehlern (429, Timeout, Connect/Reset/Closed, voruebergehend nicht verfuegbar).
• Nutzt retry_after, falls verfuegbar, ansonsten exponentiellen Backoff.
• Markdown-Parse-Fehler werden nicht wiederholt; stattdessen wird auf Klartext zurueckgefallen.

Konfiguration

Setze die Retry-Richtlinie 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,
      },
    },
  },
}

Hinweise

• Retries gelten pro Request (Nachrichtenversand, Medien-Upload, Reaktion, Umfrage, Sticker).
• Zusammengesetzte Flows wiederholen bereits abgeschlossene Schritte nicht.