After several automatic retries fail, stop and hand the decision to the person

What it is

Automatic retry is the system sampling the channel on someone’s behalf. After a few samples still fail, the channel this time is probably not “400 ms more and it will be fine”. Continuing to auto only lengthens the backoff curve and leaves people in a wait they cannot steer. Hand-off stops automatic and returns the decision: try once more, change conditions, cancel, go do something else offline. The cap is not temper. It is admitting this gear of automatic is spent.

Why it happens

Transient faults are short-lived; two or three backed-off tries already cover most of the “dropped packet + brief overload” distribution. Past that, failure is more likely a standing condition: auth expired, object gone, service in maintenance, device offline. Automatic retry has no new information about those conditions; it only delays the moment people take another strategy. While automatic is still running it is hard to insert: cancel may collide with the next auto, changing parameters may be overwritten by the next fire.

Hand-off has to say that the automatic layer ended: “retried n times, still could not load”, then a nearby manual action. If automatic still runs in the dark after hand-off, a manual tap becomes another double fire, and the hand-off is fake. Stop means stop.

Where it stops holding

Background jobs and sync queues may have a longer automatic budget because no one is watching; they still need a cap, and should become a failed state in the task list for someone to handle, not back off forever. A manual retry the person just tapped should start a fresh automatic budget, not add the previous round’s count onto “you failed again”. When the other side gives an explicit cool-off (Retry-After), honour it; do not let hand-off mean the person is now free to punch a door still cooling — show the cool-off on the manual path too. Safety writes should stop automatic even harder at hand-off, so a payment is not still firing in the dark after people have walked away.

Applying it

• Give automatic retry a small cap in count or total time (say 3 tries, or a dozen seconds). At the cap, stop and enter failure presentation.
• Hand-off copy includes “already tried automatically”, so people do not think they are being asked to tap having never tried.
• After stop, send no automatic request until a manual act or a network-restored event explicitly starts a new round.
• How to check: fail continuously. The UI should stop network activity after a bounded few tries and show a tappable next step. If a minute later requests are still going out on backoff, hand-off did not happen.

Related

• Same group: I2.13.1 Automatic retries need backoff; immediate tight retries pile onto the server · I2.13.3 Be explicit whether retry reuses the original parameters or allows the request to be edited · I2.13.4 A pattern of repeated failure suggests a systemic problem, not a flaky network blip
• Nearby: I2.08 Load failure · I2.06 Cancel during wait · I3.07 Background tasks
• Search terms: retry budget · handoff to user · stop automatic retry