NoSuchUpload
Amazon S3 NoSuchUpload means the multipart upload ID in the request no longer identifies an active multipart upload session.
Last reviewed: April 27, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does No Such Upload Mean?
S3 resolved the bucket/key context but could not find the multipart upload session referenced by UploadId. The session may have been completed, aborted by another actor, removed by lifecycle rules, never persisted correctly, or resumed from stale client metadata. Recovery normally requires starting a fresh multipart upload and rebuilding the resume state.
Common Causes
- -Lifecycle rule for aborting incomplete multipart uploads removed the session before the client resumed.
- -Another worker completed or aborted the same upload ID while a retry path still tried to upload parts.
- -Client persisted an upload ID without bucket, key, initiated timestamp, part size, or part ETag state and resumed the wrong session.
- -Queue retry or mobile resume attempts use an upload ID after a long offline delay.
- -Cleanup jobs remove stale uploads without coordinating with active resumable upload workers.
How to Fix No Such Upload
- 1Call
ListPartsorListMultipartUploadsbefore resuming and confirm the upload ID is still active for the exact bucket/key. - 2If the upload ID is gone, create a new multipart upload and restart from the source data or a verified local checkpoint.
- 3Compare lifecycle abort windows with expected upload duration and offline retry windows.
- 4Coordinate complete/abort ownership so only one worker finalizes a given upload ID.
- 5Persist upload ID, bucket, key, initiated time, part size, uploaded part numbers, and ETags atomically.
Step-by-Step Diagnosis for No Such Upload
- 1Capture bucket, key, upload ID, part number, request ID, caller, and client resume metadata from the failing request.
- 2Run
ListPartsfor the upload ID andListMultipartUploadsfor the key prefix to determine whether the session still exists. - 3Audit lifecycle rules for
AbortIncompleteMultipartUploadand compare configured days with upload age. - 4Search CloudTrail data events and application logs for
CompleteMultipartUploadorAbortMultipartUploadon the same upload ID. - 5Check whether retries, cleanup jobs, or multiple workers share the same upload ID without ownership control.
Seen in Production
- -A mobile client starts a large upload, goes offline for two days, and resumes after lifecycle cleanup aborted the incomplete session.
- -Two queue workers share one upload ID; one completes it while the other keeps uploading remaining parts.
- -A cleanup Lambda aborts old multipart uploads using an aggressive age threshold during an active slow upload.
- -A crash recovery path restores an upload ID from disk but loses the associated bucket/key and part ETag manifest.
Active Session and Part Manifest Validation
- -Validate the upload ID exists before sending any resumed
UploadPartorCompleteMultipartUpload. - -Compare persisted part numbers and ETags with
ListPartsbefore finalizing.
Lifecycle and Ownership Checks
- -Check lifecycle abort rules and cleanup jobs against real upload durations.
- -Ensure complete/abort calls are single-owner operations for a given upload ID.
Decision Shortcut: Resume vs Restart
- -If
ListPartssucceeds and part ETags match, resume the active session. - -If
ListPartsreturns NoSuchUpload or the upload ID is absent from active uploads, restart with a new upload ID. - -If another worker already completed the object, verify final object integrity instead of starting duplicate work.
Wrong Fix to Avoid
- -Do not keep retrying
UploadPartwith the same missing upload ID. - -Do not complete a multipart upload from stale local part metadata without reconciling against
ListParts. - -Do not extend lifecycle abort windows globally without also fixing resume metadata and ownership.
Implementation Examples
2026-04-27T20:15:33Z bucket=media-prod key=raw/video.mov
uploadId=VXBsb2FkIElEIG5vdCBmb3VuZA partNumber=187 status=404 error=NoSuchUpload
message="The specified multipart upload does not exist"async function uploadPartOrRestart(state, part) {
try {
return await s3.send(new UploadPartCommand({
Bucket: state.bucket,
Key: state.key,
UploadId: state.uploadId,
PartNumber: part.number,
Body: part.body,
}));
} catch (err) {
if (err.name === 'NoSuchUpload') {
return restartMultipartUpload(state.bucket, state.key);
}
throw err;
}
}aws s3api list-multipart-uploads \
--bucket media-prod \
--prefix raw/video.mov \
--query 'Uploads[].{Key:Key,UploadId:UploadId,Initiated:Initiated}'Incident Timeline
18:02 UTC
Client starts multipart upload and persists an upload ID
Signal: Upload metadata stores bucket, key, upload ID, part size, and initiated timestamp.
Why it matters: Resume safety now depends on that metadata staying synchronized with S3 session state.
19:47 UTC
The upload session is completed, aborted, or lifecycle-cleaned
Signal: Another worker finalizes the upload, cleanup aborts it, or lifecycle removes the incomplete session.
Why it matters: The old upload ID no longer accepts part operations.
20:15 UTC
A retry path sends parts to the missing upload ID
Signal: UploadPart, ListParts, or CompleteMultipartUpload fails with NoSuchUpload.
Why it matters: The session is gone; replaying the same upload ID will not recover it.
20:24 UTC
Uploader restarts or verifies completed object
Signal: The client creates a new upload ID, or verifies that another worker already completed the expected object.
Why it matters: That confirms the incident lived in multipart session lifecycle and resume state.
Seen in Production
The "Weekend Break" Upload
Frequency: medium
Example: A 100GB upload starts on Friday. A network outage occurs. The client tries to resume on Monday, but a "1-day Abort" lifecycle rule killed the session on Saturday.
Fix: Adjust lifecycle rules to 7 days and add "Session Not Found" logic to the client.
Two workers race on the same upload ID
Frequency: common
Example: One worker completes the multipart upload while another still uploads a late part.
Fix: Use owner heartbeats and single-owner complete/abort idempotency.
Wrong Fix vs Better Fix
Retry same upload ID vs validate active session
Wrong fix: Keep uploading parts with the same missing upload ID.
Better fix: Call ListParts or ListMultipartUploads; if absent, restart with a fresh multipart upload.
Why this is better: A removed upload ID cannot be resurrected by retries.
Local manifest only vs reconcile with S3
Wrong fix: Trust the local part manifest after crash recovery.
Better fix: Reconcile part numbers and ETags against ListParts before resuming or completing.
Why this is better: Local state can survive after S3 session state was aborted or completed elsewhere.
Aggressive cleanup vs ownership-aware aborts
Wrong fix: Abort incomplete uploads by age only.
Better fix: Coordinate cleanup with active workers and upload heartbeat/ownership metadata.
Why this is better: Slow but valid uploads can look stale without an owner heartbeat.
Debugging Tools
- -aws s3api list-multipart-uploads
- -aws s3api list-parts
- -CloudTrail data events for CompleteMultipartUpload and AbortMultipartUpload
- -S3 lifecycle configuration for AbortIncompleteMultipartUpload
How to Verify the Fix
- -Start a new multipart session, upload a test part, and verify it appears in
ListParts. - -Resume after an intentional client restart and confirm part manifest reconciliation works.
- -Complete the upload and verify object size, checksum/ETag expectations, and downstream reads.
- -Simulate lifecycle/cleanup abort and confirm the client starts a fresh upload instead of looping.
How to Prevent Recurrence
- -Persist multipart upload metadata atomically with bucket, key, upload ID, part size, initiated time, part ETags, and owner heartbeat.
- -Validate active upload state before every resume and before complete.
- -Align lifecycle abort windows with maximum supported upload/resume duration.
- -Make complete and abort operations single-owner actions with idempotency guards.
Pro Tip
- -treat NoSuchUpload as a restart boundary, not a transient retryable error.
Official References
Provider Context
This guidance is specific to AWS services. Always validate implementation details against official provider documentation before deploying to production.