Getting a stopped file again can mean continuing a live transfer or creating a new transfer from a saved address. I separated resume from retry in the browser. The deciding fact is whether a controllable native item still exists, rather than how similar the arrow icons look.
Resume is directed to a live native object
ActiveDownloads retains a record together with its native item. Resume is available for a paused progressing item, or an interrupted item whose native canResume says it can continue. Perform refreshes current state rather than trusting a capability flag left on an old button.
Another profile cannot send the control, and terminal completed or cancelled items leave the active collection. An old button cannot revive them. Resume calls resume on the current native object; it does not guess a new URL and call that continuation. Whether the server actually supports continuation, or requires starting again, remains a condition of the native transfer and remote response.
Restored history is not a restored live transfer
After an application restart, download history can be restored without restoring a native item. RestoredDownloads converts previously progressing or paused records into interrupted history. Runtime controls such as a persisted canResume flag are not blindly reinstated.
It validates record format, profile, path and name and reads only the bounded recent history. It neither marks interruption complete nor silently starts a replacement transfer. The person still has a decision about getting the file again, but that is a subsequent action. Separating history restoration from execution recovery makes the promise of a restarted interface much clearer.
Retry creates a new record for a terminal transfer
Retry is allowed for failed, cancelled or interrupted terminal history when no controllable transfer or pending retry remains. A saved original HTTP(S) address is required. A paused live item is not relabelled retry, and the implementation does not revisit a page and replay its whole interaction to obtain a guessed resource.
The new transfer gets its own record while the original retains its failed or cancelled history. The earlier attempt is not rewritten as though it had succeeded from the beginning. If a file arrives, normal destination selection, collision handling and transfer controls apply. Clicking retry alone does not qualify the replacement as completed.
A saved address does not guarantee that retrieval will work
Page-generated blob resources and old records without a saved source address cannot use this retry route. Non-HTTP(S) values and URLs containing username or password fields are rejected. Those cases need an explanation that the file must be obtained from the original page.
Even a valid HTTP address cannot guarantee recovery of an expired link, renewed authentication or a POST-generated result. The product documentation retains those limits. An overly broad description would encourage people to expect every stopped transfer to continue through the same button. A narrow stated contract gives a more useful recovery path than a familiar icon attached to an unsupported promise.
Keep the verification cases separate as well
Existing control tests check capability changes across pause, resume and cancel, completion winning over stale controls, and removal of canResume when a paused record is restored after restart. Retry tests separately inspect child attribution and duplicate-request blocking. A passing case for one operation does not prove another operation.
I did not newly execute the original network suite while writing this account. It explains implementation boundaries from source, unit tests and documentation. The linked synthetic package is also not a download resumer; it compares selection and byte receipts. An operational adaptation must first decide which component owns live items, persistent history and the state of new requests.