NoSuchUpload

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 CompleteMultipartUpload or AbortMultipartUpload on 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

1. 1Restart the Upload: Call CreateMultipartUpload to get a fresh ID. There is no way to recover parts from an expired ID.
2. 2Validate ID Before Resume: Always call ListMultipartUploads before resuming a transfer to ensure the ID is still active.
3. 3Sync Lifecycle Rules: Ensure your "Abort Incomplete" lifecycle rules are at least 7-14 days to allow for slow connections.
4. 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

1. 1Run aws s3api list-multipart-uploads to see if your Upload ID is still listed as active.
2. 2Check the Initiated timestamp: If it was more than 7 days ago, the ID has naturally expired.
3. 3Audit S3 Lifecycle rules: Look for AbortIncompleteMultipartUploads settings that might be aggressively cleaning up your sessions.
4. 4Review CloudTrail: Search for AbortMultipartUpload events to see if an automated script is killing your uploads.

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 UploadId with a timestamp. If now - timestamp > 6 days, proactively restart the upload.
• -Graceful Failures: In your code, catch NoSuchUpload and automatically trigger the "Start Fresh" workflow instead of looping retries.
• -Extended Lifecycle: Set AbortIncompleteMultipartUploads to 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.

Related Errors

Decision Support

Official References

• -S3 Multipart Upload API
• -Aborting Incomplete Uploads
• -AWS S3 Multipart Upload Documentation
• -AWS Official Documentation