effect-errors-retries

Retry strategies with backoff and timeouts handle transient failures in service calls. Define retry schedules that increase delay between attempts, add jitter to prevent thundering herd, and set absolute timeouts to fail fast. Map specific error types to retry policies at service boundaries.

TaggedError types categorize errors into domain boundaries, separating recoverable from permanent failures. Use catchTag to match and handle specific error types at the point where recovery is possible, then map errors upward through layers only when unrecoverable.

Classify errors by domain and recoverability: transient network failures warrant retries; validation errors and permission denials do not. TaggedError types let you mark each error category, then apply retry schedules selectively to errors where retrying has a reasonable chance of success.

Yes. TaggedError types and retry schedules work across any service boundary. Map HTTP status codes, database error codes, and third-party exception types into your domain error taxonomy, then apply consistent retry and timeout policies.

After all retries fail or timeout expires, the error propagates to the caller as an unrecoverable failure. Use catchTag to implement fallback logic—circuit breakers, degraded responses, or alerts—before the error surfaces to end users.