When the Upload Link Runs Out Mid-File: A Renewal Trace That Keeps the Selection

A signed upload address usually has a short life. If it expires while a person is partway through a big file, a bad interface drops the selection and says to try again. This article proposes an interaction trace that keeps the file, renews permission, and avoids repeating writes whose outcome is unknown. It is a conditional design, not a claim about any product.

The artifact: expiry renewal trace

A trace is a sequence of observable events with the expected state after each. Keep these pieces of state on the page:

the in-memory file object the person selected (never discard it on an error)
an upload session id
per chunk state: pending, sent_unconfirmed, confirmed, expired_rejected
a renewal counter

Branches by how the expiry shows itself

Before start. The first request is refused as expired with a clear signal that nothing was written. Request a fresh address and begin.
Explicit rejection mid transfer. The response clearly says the address expired and the chunk was not stored. Mark the chunk expired_rejected, request new addresses for the remaining chunks, and continue. This costs one renewal.
Ambiguous failure. The request timed out or the connection broke, so you cannot tell whether the chunk was stored. Do not resend. Ask the server for the session's chunk status through a freshly authorised call. Resend only if the server says the chunk is absent, and only once.
Page reloaded. In-memory file is gone. Show the file name and size that were being uploaded and ask the person to select it again. Compare the new selection with the stored size and name, and with a sampled fingerprint if you have one. If they match, resume. If they differ, offer a new upload. Whether any browser feature can keep a file handle across reloads varies, so treat that as optional.

Renewal rules

Renewal requires a valid logged in session. If the login itself has expired, ask the person to sign in, then continue with the same file.
Limit renewals per upload, for example two in a row without progress. After that, stop with a plain message and keep the file selected.
A renewed address should be scoped to the same session and chunk range, not a new upload.

Worked hypothetical example

File of 5 chunks. Trace:

Chunks 0, 1, 2 are sent and confirmed.
Chunk 3 is sent with an old address and the server explicitly says expired and not stored. Chunk 3 becomes expired_rejected. Renewal counter is 1.
The page requests fresh addresses for chunks 3 and 4, keeping the file object. The screen still shows the file name and 3 of 5 confirmed.
Chunks 3 and 4 are sent and confirmed. 5 of 5 confirmed.
The final integrity check described in the session proceeds as usual.

Ambiguous variant: at step 2 the connection drops instead. Chunk 3 becomes sent_unconfirmed. After reconnect the page asks for session status. If the server lists chunks 0 to 3, chunk 3 is marked confirmed and only chunk 4 is sent. If the server lists 0 to 2, chunk 3 is sent once more. If the status call fails, the page stops and shows a retry button.

Stop conditions

Renewal limit reached.
Reselected file does not match.
Status check cannot complete.
Server refuses renewal for the session, for example because it was cancelled.

In each case keep the visible file name, show what is confirmed, and give a single clear next action.

Proposed acceptance tests (to be run, not yet performed)

Force the address to expire after chunk 2 and expect 5 of 5 completion with one renewal and the file never reselected.
Cut the connection during chunk 3 and expect a status query before any resend.
Reload mid upload and expect a prompt to reselect that names the file, with a mismatch test using a different file.
Expire the login session and expect sign in, then continuation.
Refuse two renewals and expect a stop that preserves the selection.
Check the screen reader announcement for each state change.

A renewal flow reduces lost work, but does not replace the server side integrity check.