Readonly nextThe wait, in milliseconds, before the next operation, as the last recorded outcome decided it. Reading it has no side effects.
Applies a server-directed retry time.
The value replaces the base of the delay computation and restarts the doubling sequence, taking precedence over the current regime's initial delay — including the extended regime's. The computed delay is still bounded by the regime's ceiling. The value stays in effect until another one arrives, including across a reset. Non-finite or negative values are ignored; callers are expected to have validated and capped the value at its point of entry.
Records a failed attempt and decides the wait before the next one.
The state advances before the wait is computed, so RetryState.nextDelay always reflects the failure just recorded. Callers should read it in the same turn, before any other outcome is recorded.
Generated using TypeDoc
Tracks how long a data source, or another long-running component, should wait before its next attempt.
Recording a failure advances the state and decides the next wait, which RetryState.nextDelay reports: the delay doubles with each consecutive failure, from the current regime's initial delay up to its ceiling, less a random jitter of up to half of it, and never less than the operating cadence. An unexpected failure moves the state to the extended regime, which raises both bounds; a normal failure that follows cannot lower them. The bounds stay raised until the reset policy is satisfied. A server-directed retry time, once applied, replaces the regime's initial delay as the base of the computation; the ceiling continues to apply.
Recording a success sets the next wait back to the operating cadence, even while the retry state is raised, because a backoff wait applies to a retry and not to every operation.
A retry state never starts timers, performs I/O, or logs; callers schedule the waits it computes. Use one instance per component; instances are never shared between components.