NoSuchUpload
AWS S3 NoSuchUpload is an error indicating that the specified Multipart Upload ID is invalid, expired, or has already been completed or aborted. It prevents further parts from being uploaded or the session from being finalized.
Last reviewed: March 18, 2026|Editorial standard: source-backed technical guidance
What Does No Such Upload Mean?
A NoSuchUpload error signals that the multipart upload session has been "killed" in the S3 backend. By default, S3 keeps upload IDs active for 7 days. If an upload is not completed or aborted within this window, S3 purges the ID and its associated parts. This error is fatal for the specific Upload ID; you cannot "fix" it without starting a new session via CreateMultipartUpload.
Common Causes
- -Session Expiration: The upload ID exceeded the 7-day retention period or a custom S3 Lifecycle rule aborted it earlier.
- -Premature Completion/Abort: Another thread or a cleanup script called
CompleteMultipartUploadorAbortMultipartUploadon the same ID. - -Client Persistence Failure: The client crashed and attempted to resume using a corrupted or non-existent Upload ID after restart.
- -Lifecycle Rule Conflict: A bucket-level rule (AbortIncompleteMultipartUploads) is set to a window shorter than your actual upload duration.
How to Fix No Such Upload
- 1Restart the Upload: Call
CreateMultipartUploadto get a fresh ID. There is no way to recover parts from an expired ID. - 2Validate ID Before Resume: Always call
ListMultipartUploadsbefore resuming a transfer to ensure the ID is still active. - 3Sync Lifecycle Rules: Ensure your "Abort Incomplete" lifecycle rules are at least 7-14 days to allow for slow connections.
- 4Persist Metadata: Save the Upload ID and ETag list in a persistent store (like DynamoDB) immediately after starting the session.
Step-by-Step Diagnosis for No Such Upload
- 1Run
aws s3api list-multipart-uploadsto see if your Upload ID is still listed as active. - 2Check the
Initiatedtimestamp: If it was more than 7 days ago, the ID has naturally expired. - 3Audit S3 Lifecycle rules: Look for
AbortIncompleteMultipartUploadssettings that might be aggressively cleaning up your sessions. - 4Review CloudTrail: Search for
AbortMultipartUploadevents to see if an automated script is killing your uploads.
The 7-Day Expiry vs. Lifecycle Rules
- -S3 Default: Sessions last 7 days. If you are uploading a multi-terabyte file over a slow link, you might hit this.
- -Lifecycle Rules: These can be set to 1 day or even less. Always check your bucket policy if NoSuchUpload happens within 24 hours.
Resumable Upload Architecture
- -Safe Resume: Check
ListPartsto see what S3 actually has before sendingUploadPart. IfListPartsthrows NoSuchUpload, restart the whole process.
Implementation Examples
try {
// Try to upload a part
await s3.send(new UploadPartCommand({ ...params, UploadId: storedId }));
} catch (err) {
if (err.name === 'NoSuchUpload') {
console.error("Session expired. Restarting upload...");
const newSession = await s3.send(new CreateMultipartUploadCommand({ Bucket, Key }));
const newId = newSession.UploadId;
// Update your database with the newId and restart
}
}aws s3api list-multipart-uploads --bucket my-large-data-bucket \
--query 'Uploads[?Key==`target-file.zip`].UploadId'How to Verify the Fix
- -Start a new session, upload a small test part, and verify it appears in
list-parts. - -Complete the upload and confirm the object is accessible in the S3 bucket.
- -Confirm that your retry logic correctly triggers a "fresh start" when NoSuchUpload is caught.
How to Prevent Recurrence
- -Database Backing: Store every
UploadIdwith a timestamp. Ifnow - timestamp > 6 days, proactively restart the upload. - -Graceful Failures: In your code, catch
NoSuchUploadand automatically trigger the "Start Fresh" workflow instead of looping retries. - -Extended Lifecycle: Set
AbortIncompleteMultipartUploadsto a generous window (e.g., 14 days) for non-critical buckets. - -Pro-tip: Use the S3 Transfer Manager (in Java/JS SDKs) which handles multipart complexity, retries, and session management automatically.
Decision Support
Compare Guide
409 Conflict vs 412 Precondition Failed: When to Use Each
Choose 412 when If-Match or If-Unmodified-Since checks fail; choose 409 for state conflicts without failed precondition headers during concurrent updates.
Playbook
Conflict and Concurrency Playbook (409 / 412 / OptimisticLock)
Use this playbook to separate true write conflicts from stale precondition failures, then apply safe re-fetch, optimistic-lock, and retry choices.
Official References
Provider Context
This guidance is specific to AWS services. Always validate implementation details against official provider documentation before deploying to production.