When is an uploaded attachment ready to use?

Give progress a precise meaning

The component caps transfer progress at 99%. A file is appended to the business attachment list only when the backend reports processingStatus = ready. queued and processing keep it pending; other states retain an explanation and a recheck path.

This distinction matters when a server has received the bytes but is still scanning or generating a preview. Showing a completed business attachment too early can let a user submit an item that is not yet available.

Model the attachment independently

A useful simplification is to represent transfer and processing separately, then derive whether the business form can submit. Unknown processing states should stay unavailable until the API contract explains them. The following sketch illustrates that decision and does not implement scanning.

// Teaching sketch; server processing remains authoritative.
type Attachment = {
  transfer: "idle" | "sending" | "stored" | "failed";
  processing: "unknown" | "queued" | "processing" | "ready" | "rejected";
};
const canAttach = (file: Attachment) =>
  file.transfer === "stored" && file.processing === "ready";

Resuming needs server knowledge

The reviewed component obtains received chunk indices from the server before sending missing chunks. A local percentage cannot establish that a chunk was committed. Pause aborts the active XHR; cancelling also requests server cleanup when an upload ID exists.

The current hashing path reads the entire file with arrayBuffer() before SHA-256. For larger mobile files this deserves memory profiling. Incremental hashing or worker-based work is a possible next step; a worker moves work off the UI thread but does not automatically reduce total memory.

Media resources need explicit owners

The component revokes object URLs, stops media tracks, aborts pending XHRs and clears its processing poll when unmounting. Late callbacks still deserve separate tests, especially canvas conversion or an upload response arriving after navigation. Cleanup code being present does not prove every race is covered.

A future acceptance matrix should include rejecting file access, a failed scan, lost acknowledgement after chunk storage, navigation during preview generation and repeated retry. The public case page links earlier evidence; this note only adds the current reading observations.