Skip to content
AITroveRead. Build. Understand.
Reading list
Make this comfortable

Resumable Transfer Parts and Integrity

Last updated: 4 Oct 20266 min read
tutorial
IntermediateBy AITrove Editorial

A resumable upload divides one object into parts and records which bytes or numbered parts the storage service has accepted. It reduces retransmission after a network break, but completion is a separate server decision. Client-reported progress measures sent bytes, not durable, inspected, or usable bytes. Each part belongs to one upload session, object key, owner, and expiry. The final object must be assembled under the storage service’s rules and checked for expected length and a supported checksum before it is attached to a case. Part identifiers and provider tags are protocol data; a final multipart tag should not be assumed to be a whole-file digest.

Working case

Reviewer 29 uploads a 47 MiB video for case 47 in five parts. The fourth part times out after storage may already have accepted it. The client asks the server for current part state and retries only if the authoritative record still needs it. The server keeps upload 62 scoped to reviewer 29 and case 47. A second tab cannot finish upload 62 with a different file. After all five parts are listed, the server completes the object and checks size and the chosen full-object checksum. It then marks the transfer complete, while content inspection remains pending.

Implementation boundary

javascript
function completedPartBytes(parts) {
  return parts.reduce((bytes, part) => bytes + (part.accepted ? part.size : 0), 0);
}
console.log(completedPartBytes([{ size: 8, accepted: true }, { size: 8, accepted: false }]));
// Output: 8

Choose part size and maximum count according to the selected storage service, not an assumed universal constant. Bind initiation, part authorization, completion, and abort to the same application asset. Require the client to present an upload session ID, but look up owner and object key on the server. Use storage-reported part identifiers and checksums where supported; do not accept a forged client list as proof. Recheck object metadata after completion and compare an application-level digest if the product requires end-to-end integrity. Record retryable and permanent failures separately. Expire abandoned sessions and abort incomplete multipart storage to prevent orphaned-part cost. Progress UI should distinguish sending, assembling, verifying, and processing.

Cost and boundaries

For n bytes and part size s, transfer uses about n divided by s parts plus initiation and completion calls. Smaller parts reduce retransmitted bytes but increase requests and metadata; excessive parallelism competes for client bandwidth and server limits. Checksum computation touches O(n) bytes and can be streamed with bounded memory. Retained incomplete parts consume storage until completion or abort, so lifecycle cleanup is a cost control as well as housekeeping. Track orphaned session age, part retry rate, checksum mismatch, completion failures, and time from 100 percent sent to usable asset.

Failure trace

The progress bar reaches 100 percent and the UI exposes a download link, but final assembly failed. A reviewer sees a missing or truncated video. Gate access on verified completion plus inspection, not browser progress. Another system retries a timed-out part by creating a second upload session and loses the original accepted parts. Reconcile against the original session first. Test duplicate part number, wrong order, stale upload ID, part from another user, completion timeout, mismatched digest, abort during active requests, and cleanup of an abandoned multipart session.

Verification

  • All accepted parts belong to one authorized session.
  • Full-object length and integrity are checked after assembly.
  • Abandoned multipart sessions are eventually aborted.

Practice drill

Begin upload 62 and record five planned parts with their expected byte ranges. Force a timeout on part four after the storage write, query authoritative state, and finish without uploading parts one through three again. Submit a part list with a missing item and reject completion. Corrupt one local part and verify the full-object check fails. Cancel the upload, then confirm no public asset appears and the cleanup job releases incomplete storage after its defined grace period.

Decision note

Separate sent-byte progress from verified object completion, and make retries reconcile one owned session.

Common Mistakes

  • Equating browser progress with durable completion.
  • Treating a multipart tag as a whole-file digest.
  • Starting a fresh session after every uncertain part response.

Connected lessons

File Ingestion and Private Asset Lifecycle; Upload Intake Budgets and Storage Ownership; File Quarantine, Inspection, and Derived Previews; Private Asset Downloads, Revocation, and Expiry; Multipart Upload Progress and Retry Boundaries; Upload Intake Budgets and Storage Ownership; Large Export Download and Integrity.

Apply and check

Build Project: private evidence file lifecycle and review Web Development: file and email delivery decisions quiz.

web-tech
web-development
Storage details