Choose the recovery goal
A retry is useful only while the requested resource can still help the task. An owned on-demand download may tolerate a longer recovery interval than a near-live presentation. Define that usefulness window before choosing how many repeated requests a component may make.
List which failures are candidates for recovery and which require another action, such as correcting an address or renewing an authorised session through the documented flow. A retry loop should not become a way to evade an access decision or conceal a persistent packaging error.
Combine a deadline with an attempt limit
Choose both an elapsed-time budget and a maximum attempt count for the component under your control. Include the initial request in your accounting. Bound the wait as well as the number of calls so a user is not left in an endless loading state.
A hypothetical file task might still benefit after a brief pause, while a live segment can become obsolete as the window advances. Those examples illustrate policy design, not recommended universal timings. The actual protocol, client and service requirements determine the values.
Respect response guidance
Retry-After can communicate a waiting period or a date in relevant HTTP responses. If your component uses it, parse the documented form and apply it within the task's recovery policy. Do not promise that every player or intermediary honours the field identically.
Avoid independently multiplying retries at several layers. A client, proxy and worker each performing several attempts can create more origin traffic than expected. Document which layer owns recovery and how the others report failure. Preserve enough evidence to distinguish an original failure from later repeated requests.
Make the stop useful
When the recovery budget ends, provide a clear state and preserve the error context. Offer a deliberate user action if appropriate, rather than immediately beginning the same loop again. For a live presentation, the next valid action may concern a current position, but it must follow the player's supported behaviour.
Retry-After documentation by Mozilla Contributors is available under CC-BY-SA 2.5 or later. The budget method here is original engineering guidance. Validate it in controlled failure scenarios when implementing it, and report actual attempt counts and elapsed time separately from any claim about successful playback.
Questions answered
Is an unlimited retry loop a reliability feature?
It can prolong failure and multiply traffic. Define the useful recovery window and a stopping condition.
Should a live segment and a full file always use the same retry policy?
No. Their useful lifetimes and task deadlines can differ.
Sources & further reading
Official references for the subjects discussed. Service terms and device software can change.