Make retrying an attachment different from choosing a file
A file chooser answers which local file the person has selected. It is not a reliable substitute for an explicit instruction to send that file again. Treating those two actions as the same event can leave a customer repeating a gesture while the application does nothing.
The following fictional enquiry lets a buyer attach a specification for staff review. Its inspected browser treats selecting the same file again as a dismissed or unchanged selection, rather than firing the changed-selection event used by the application. The precise browser behaviour belongs to this fixture; another environment must be observed separately.
The case ends with a receiving record and an explicit file reference. It does not treat an upload as approval of the specification, acceptance of an order or confirmation of a payment.
Establish what happened before suggesting a retry
Request Q-61 is a saved draft. The buyer chooses the synthetic PDF F-61, which contains reference SPEC-F61. The application retains its selected File object and starts upload attempt A-61 when the input fires change.
The isolated receiver's injected failure stops A-61 before storage. Its inspected attempt record confirms that no attachment was stored. This is stronger evidence than a generic network error. In an ordinary unresolved timeout, staff would first need to reconcile whether the receiver had stored the file.
The page tells the buyer to choose the file again. The buyer does so, but the chooser still has F-61 selected. In this fixture, the input reports cancel; there is no change event, and the upload handler never starts another request. A premature “retrying” label makes the silence look like a slow transfer.
| Observation | What it establishes |
|---|---|
| A-61 stops before storage in the isolated receiver | This inspected attempt stored no attachment |
| Input still holds F-61 | The selected file remains available in this page session |
Same-file reselection yields cancel in this browser |
No changed-selection event occurred |
| Network trace has no A-62 request | The second transfer did not start |
| “Retrying” remains visible | Display state is ahead of the action it claims |
The fault lies between user intention and the action trigger. Increasing the upload timeout or changing the file extension would not make an absent request appear.
Read the platform boundary narrowly
The HTML file-input specification distinguishes the selected file list from picker events. It leaves room for different interpretations of dismissal and unchanged selection, including when a person chooses the same files again.
The application therefore needs a supported retry action that does not depend on a chooser producing a different selection. This is separate from reading the actual file bytes correctly, validating permitted file types or deciding whether an uncertain earlier request may be repeated.
A selected File also belongs to the current page's available state. The proposed correction does not promise to retain it after reload, browser closure or another action that removes the selection. Those conditions need an honest request to choose the file again.
Separate the three available actions
The corrected interface distinguishes Retry this attachment, Choose another file and Remove the selection. Their effects are documented separately.
Retry operates on the retained F-61 object after the application has established that A-61 stored nothing and the user explicitly requests another attempt. The upload indicator begins only when A-62 is actually started. While that attempt is active, the interface prevents another local retry action from starting concurrently.
Choose another file opens the native picker. A changed selection becomes a new candidate with its own displayed name and inspected content reference. Dismissing the picker does not claim that an upload started. Removing the selection clears the candidate without inventing a deletion of an attachment already held by the receiver.
Server-side permissions and the receiving contract continue to apply. A disabled button alone cannot determine whether another direct request is authorised or whether a previous transfer already exists.
Complete the receiving check
In the fictional retest, the buyer activates Retry for F-61. The trace records A-62 starting once. The isolated receiver accepts the actual PDF content and associates attachment AT-61 with Q-61. Its stored reference and the document's SPEC-F61 content agree with the selected candidate.
The interface then shows the stored attachment result. It no longer offers an immediate retry for that completed transfer. Staff can retrieve AT-61 from Q-61 and see that it is awaiting specification review, not approved for production.
A later choice of F-62 is visibly different. Its content says SPEC-F62, and the fixture treats it as a proposed replacement requiring the business's defined review. The first attachment's identity and history do not disappear simply because both files could have the same local filename.
Examine the contrary paths
| Case | Expected behaviour |
|---|---|
| Same F-61 selected again without a changed-selection event | No claim that a new transfer started |
| Picker dismissed while F-61 remains selected | Existing candidate remains; no invented upload |
| Explicit retry after verified no-store A-61 | A-62 starts with F-61 and receives its own result |
| Earlier result remains uncertain | Reconcile before permitting a new attempt |
| Page reload has lost the selected object | Ask the buyer to select a file; do not promise a retained attachment |
| Different F-62 selected | Show and process the distinct candidate under the agreed replacement rule |
| Unrelated request Q-70 | Its attachments and review state remain unchanged |
A project should also check the actual file limits, type validation and rejected-content explanation. These remain independent requirements. The fixture does not weaken them to make retry convenient.
Put the task into the form's acceptance record
Record the tested environment, picker event sequence, request trace and receiving evidence. State which result was known before retry, and keep the customer's instruction separate from automatic recovery behaviour.
For a commerce journey or a customer portal, the same design discipline helps distinguish choosing information, sending it and receiving a business decision. The project conversation should identify which of those actions is actually failing before anyone promises a new upload feature.