Auto-retry needs a hard cap
Aliases: retry cap · retry limit · bounded retry
What it is
A transient fault is worth trying again automatically, but automatic retry must stop after a finite number of attempts and hand control back. Unbounded retry turns one failure into an endless wait, turns the server into a larger incident, and makes “still trying” indistinguishable from “already dead.” This entry is only about count and stopping. It is not about which acts must never auto-retry, and not about cancel during retry.
Why it happens
Auto-retry assumes the fault is brief and independent. Real faults are often persistent: auth is dead, quota is gone, the other end is down. Each retry pays another wait on the same error; attention is held by a spinner, and the person can neither change a parameter nor leave. On the server, unbounded retry is a synchronized stampede. A cap splits “a transient worth betting on” from “a persistent case that needs a different strategy”: at the cap the surface becomes an outcome plus a next step, not an eternal progress state. Backoff (growing intervals) reduces impact but does not replace a cap—backoff only stretches the unbound.
Studying it
Inject a persistent fault and compare no cap, a fixed N, and N with backoff.
Independent variables: max attempts, interval policy, whether failure becomes a terminal state on the surface. Dependent variables: time until abandonment, duplicate requests reaching the server, rate of treating a persistent fault as “still loading.”
Lab networks can be jittered on purpose. Add a condition that never recovers, specifically to see whether the cap actually returns control.
Where it stops holding
Long tasks the user explicitly allowed (download, sync) may cap on time rather than count, but still need a perceptible stop and a summary. On a critical path, a single transient timeout may cap at one or two; a cap of several dozen is no cap. When the client clock is wrong, count attempts, do not rely on wall time alone.
Applying it
- For each auto-retry class, write the max count and the surface that follows: stop the spinner, show the failed outcome and the next step.
- Use backoff for intervals, but hard-code total attempts in the client; forbid re-entering an unbounded loop from a failure handler.
- Do not let the page, the SDK, and the gateway each retry the same user-visible request uncoordinated; count the total as the one the person perceives.
- Verify by taking the other end down and watching when the UI stops retrying and how many times the same request appears in server logs. A spinner past the agreed count, or a rising log, means the cap is not in effect.