pub enum RetryStep<T, E> {
Done(T),
DoneQuiet(T),
Fail(E),
Retry {
error: E,
delay: Duration,
cause: String,
},
}Expand description
One attempt’s outcome for the step-based retry engines
(retry_steps_sync / retry_steps_async).
The operation closure owns both classification and the backoff duration;
the engine owns everything a hand-rolled loop repeatedly gets wrong — the
attempt cap, the wall-clock deadline, backoff accounting, and the full
warn / giving-up / succeeded log lifecycle. This is the single primitive
every retry ladder in the tree routes through: a publisher that needs a
bespoke delay (unjittered exponential, a linear 5·attempt ladder, a
rate-limit reset window) or a bespoke classifier (transient-output markers,
index-propagation lag, a partial-upload probe) expresses it in the closure
instead of re-implementing the loop and drifting from the others.
The ControlFlow-based retry_sync / retry_async adapters and the
HTTP wrappers are themselves thin layers over these engines, so a fixed
RetryPolicy and a caller-owned delay share one loop, one deadline check,
and one set of log lines.
Variants§
Done(T)
Stop and succeed with this value. When at least one retry preceded it,
the engine emits the recovery (“succeeded after N attempt(s)”) line —
so reserve Done for a clean success the operator wants confirmed.
DoneQuiet(T)
Stop and succeed with this value, but suppress the recovery line. For a terminal outcome that is success-valued yet carries its own narrative — an idempotent skip, a tolerated degraded disposition (a kept-stale asset) — where a “succeeded after N attempt(s)” note would contradict the closure’s own log line rather than confirm a recovery.
Fail(E)
Stop and fail with this non-retriable error (a 4xx-style fast-fail). The engine emits no giving-up line: the operation already classified this as terminal and knows why.
Retry
A retriable failure. If an attempt and the wall-clock budget both
remain, the engine sleeps delay (recorded as run backoff) and re-runs
the closure; otherwise it stops and returns error. cause is the
compact, human-readable reason rendered in the per-attempt warn line
(e.g. "status=503", "sparse-index propagation lag").