sleep-retry-logic

[tobixen]

Some servers sometimes have transient errors.

My idea is to make it possible for the client to sleep and retry on transient errors. This should be a configurable opt-in feature.

It goes in under the "features"-section in the server configuration. Perhaps this "feature" can be called "high-availability" with type "server-peculiarity". Or perhaps it should be more explicit, "retry-on-failure" of type "client-feature". Extra configuration parameters should indicate the sleep before the first retry (one may want to keep it short - perhaps all that is needed is a retry, without any sleep), the sleep between subsequent retries, the max number of retries. May consider supporting growing sleep intervals too.

[tobixen]

(The text below was added by Claude, the AI. I think PUT and DELETE should be idempotent in CalDAV, and POST is not used that often. Exponential back-off may not make sense in cases like network outages)

Design Suggestions

Naming

I'd suggest retry-on-transient-error over high-availability - the latter might be misleading since this handles server instability rather than true HA (load balancing, failover, etc.).

Configuration Structure

retry-on-transient-error:
  enabled: true
  max_retries: 3
  initial_delay: 0.5        # seconds before first retry
  backoff_factor: 2.0       # exponential backoff multiplier
  max_delay: 30             # cap on delay between retries
  jitter: true              # add randomness to avoid thundering herd

Which Errors to Retry

Consider categorizing errors:

Transient (retry by default):

• HTTP 500, 502, 503, 504 - server errors
• HTTP 429 - rate limited (should respect Retry-After header if present)
• Connection timeouts/resets

Context-dependent:

• AuthorizationError (403) - usually permanent, but robur shows it can be transient for newly created resources

Permanent (never retry):

• HTTP 400, 401, 404 - client errors
• HTTP 405, 409 - method/conflict errors

Idempotency Consideration

Safe to retry: GET, HEAD, PROPFIND, REPORT, OPTIONS
Risky to retry: PUT, POST, DELETE, MKCALENDAR (might succeed but return error)

Could add retry_safe_methods_only: true option to only retry read operations.

---

🤖 Generated with Claude Code