Opening the page again just to retry a download can disturb a draft and its place in the workflow. I request the recorded resource through its original profile session. The design preserves attribution without copying cookies or borrowing a login from another visible window.
Do not guess the original resource from the current page
RetryURL reads the sourceURL retained in history and checks string length, URL validity, HTTP(S), and absence of username/password fields. A similar visible link is not guessed to be the original resource, and a form submission is not replayed. The retry route stays small when the recorded resource is known.
State must also qualify: failed, cancelled or interrupted history, with neither canCancel nor retrying still active. A live transfer should use its existing controls first. Possessing an address does not guarantee that the server will return identical content or that authorization remains valid, so URL eligibility is a precondition rather than a completed-download claim.
Send the request through the record profile session
BrowserHost finds a record owned by the current profile and calls getSession(d.profileId).downloadURL. It does not navigate the draft tab or create a replacement tab. Preserving the original profile means using that session's native download route, a specific implementation choice rather than a vague claim about remembering an account.
No cookies are extracted and copied into another browser. Yet the same session does not guarantee an indefinitely valid login. Reauthentication or an expired link can make the new request fail. Preserving account context differs from proving remote authentication succeeded; the latter still requires an actual response and a usable file result.
Do not turn repeated clicks into repeated transfers
RetryDownloads.start tracks pending work by profile and original record ID, and also blocks another request for the same source URL within that profile. Serializing the same resource across project histories helps attribute the next native child precisely instead of racing two possible parents.
A synchronous dispatch failure releases pending state so the original can become retryable again; a linked child finishing also releases it. This Map coordinates in-flight retries in memory. It is not a persistent deduplication journal across restarts or an exactly-once guarantee for server requests. The explanation preserves those limits instead of adding stronger execution language than the implementation supports.
Attribute the child through profile and URL-chain matching
For a new native download without a source webContents, claim compares its profile and URL chain with pending retries. The first matching child inherits the original tabId and workspaceId. A chain can retain the original resource through a redirect; an identical URL in another profile cannot claim the association.
The child keeps a separate ID and state, leaving the original failed record intact. This attribution does not establish that the content is correct. The new file still needs its own size and content evidence. Which task initiated a retry and whether its result is actually the expected artifact remain separate questions with separate observations.
Preserving a draft needs both request and page comparisons
The existing UI test uses a local receiver to check the fixture cookie, a single extra request after duplicate clicks, and the resulting file hash. It also checks the original active tab, draft value and page timeOrigin. Looking only at the file would miss a retry that unnecessarily reloads or replaces the working page.
For this article I read those selected test ranges without newly running a service or fixture server. The synthetic receipt module compares supplied bytes and implements neither login nor retry. Adapting the design requires separate connections for recorded addresses, session selection, duplicate locks, child attribution and actual content checks. Each should retain its own evidence rather than inheriting success from the retry button.