Retry Policy
このコンテンツはまだ日本語訳がありません。
Retry policy
Section titled “Retry policy”- Retry per HTTP request, not per multi-step flow.
- Preserve ordering by retrying only the current step.
- Avoid duplicating non-idempotent operations.
Defaults
Section titled “Defaults”- Attempts: 3
- Max delay cap: 30000 ms
- Jitter: 0.1 (10 percent)
- Provider defaults:
- Telegram min delay: 400 ms
- Discord min delay: 500 ms
Behavior
Section titled “Behavior”Discord
Section titled “Discord”- Retries only on rate-limit errors (HTTP 429).
- Uses Discord
retry_afterwhen available, otherwise exponential backoff.
Telegram
Section titled “Telegram”- Retries on transient errors (429, timeout, connect/reset/closed, temporarily unavailable).
- Uses
retry_afterwhen available, otherwise exponential backoff. - Markdown parse errors are not retried; they fall back to plain text.
Configuration
Section titled “Configuration”Set retry policy per provider in ~/.coderclaw/coderclaw.json:
{ channels: { telegram: { retry: { attempts: 3, minDelayMs: 400, maxDelayMs: 30000, jitter: 0.1, }, }, discord: { retry: { attempts: 3, minDelayMs: 500, maxDelayMs: 30000, jitter: 0.1, }, }, },}- Retries apply per request (message send, media upload, reaction, poll, sticker).
- Composite flows do not retry completed steps.