effect-scheduling

Use Effect.retry with Schedule.exponential(base), piped through Schedule.jittered and Schedule.upTo to bound attempts. Effect.retry only reruns typed failures, not defects or interruption, so keep retried operations idempotent.

Effect.retry reruns an effect when it fails with a typed error, while Effect.repeat reruns it after each success. A typed failure stops repetition unless handled first, and the source effect always runs once before the schedule is stepped.

Use Schedule.modifyDelay to compare the computed backoff with the provider's retry-after value and take the maximum via Duration.max. Apply this only to typed rate-limit or transient failures, never to authentication or validation errors.

No, Schedule.tapInput was removed in Effect v4. Use Schedule.tap instead, which receives full metadata including attempt, input, output, duration, and elapsed for observing schedule decisions.

Use TestClock instead of real sleeps when testing time policies. TestClock lets you advance virtual time deterministically, so backoff, polling intervals, and timeouts can be verified without slowing down the test suite.

Do not retry non-idempotent writes unless an idempotency key, transaction, or equivalent guarantee makes replay safe. Also avoid retrying authentication, validation, quota exhaustion, or permanent not-found failures without an explicit reason.