hashicorp/terraform · error

not all parts uploaded successfully, multipart upload aborte

Error message

not all parts uploaded successfully, multipart upload aborted

What it means

Raised when the number of successfully-collected part responses (commitMultipartUploadPartDetails) does not equal the number of source blocks after all workers finished. As a safety measure it then aborts the in-flight multipart upload via AbortMultipartUpload (multipart_upload.go:137-143) so no partial object is committed. It indicates parts were lost relative to the planned split.

Source

Thrown at internal/backend/remote-state/oci/multipart_upload.go:147

		commitMultipartUploadPartDetails[i] = objectstorage.CommitMultipartUploadPartDetails{
			PartNum: common.Int(partNumber),
			Etag:    common.String(etag),
		}
		i++
	}

	if len(commitMultipartUploadPartDetails) != len(sourceBlocks) {
		abortReq := objectstorage.AbortMultipartUploadRequest{
			UploadId:      multipartUploadResponse.MultipartUpload.UploadId,
			NamespaceName: multipartUploadResponse.Namespace,
			BucketName:    multipartUploadResponse.Bucket,
			ObjectName:    multipartUploadResponse.Object,
		}
		_, abortErr := multipartUploadData.client.objectStorageClient.AbortMultipartUpload(context.Background(), abortReq)
		if abortErr != nil {
			logger.Error(fmt.Sprintf("Failed to abort multipart upload: %s", abortErr))
		}
		return fmt.Errorf("not all parts uploaded successfully, multipart upload aborted")
	}

	commitMultipartUploadRequest := objectstorage.CommitMultipartUploadRequest{
		UploadId:           multipartUploadResponse.MultipartUpload.UploadId,
		NamespaceName:      multipartUploadResponse.Namespace,
		BucketName:         multipartUploadResponse.Bucket,
		ObjectName:         multipartUploadResponse.Object,
		OpcClientRequestId: multipartUploadResponse.OpcClientRequestId,
		RequestMetadata:    multipartUploadRequest.RequestMetadata,
		CommitMultipartUploadDetails: objectstorage.CommitMultipartUploadDetails{
			PartsToCommit: commitMultipartUploadPartDetails,
		},
	}
	_, err = multipartUploadData.client.objectStorageClient.CommitMultipartUpload(context.Background(), commitMultipartUploadRequest)
	if err != nil {
		return fmt.Errorf("failed to commit multipart upload: %s", err)
	}

View on GitHub (pinned to c9def3e214)

Solutions

  1. Re-run the apply; the abort leaves the bucket clean and a fresh attempt usually completes all parts.
  2. Inspect TF_LOG for the worker error that preceded the count mismatch (the matching 'failed to upload part %d' or 'error reading source block').
  3. Reduce concurrency pressure by lowering defaultNumberOfGoroutines or splitting the configuration into smaller states.
  4. Ensure stable network/credentials for the whole upload window; mid-upload auth expiry can drop workers.
Defensive patterns

Strategy: retry

Validate before calling

// No pure pre-check; ensure balanced bookkeeping so every block yields a response
// (each worker must wg.Done() and push a response or error for every block it pulls).

Try / catch

if len(commitMultipartUploadPartDetails) != len(sourceBlocks) {
    // abort then return error (the lib does AbortMultipartUpload here)
    return fmt.Errorf("not all parts uploaded successfully, multipart upload aborted")
}

Prevention

When it happens

Trigger: After wg.Wait() and error collection (multipart_upload.go:112-121), len(commitMultipartUploadPartDetails) != len(sourceBlocks) at line 136. Reachable when workers fail to push a response for every block (a worker exited early without Done, or responses were dropped) and the prior error checks did not already return.

Common situations: A worker hit a hard error path that failed to balance Done/response bookkeeping, leaving fewer responses than blocks; SDK edge cases producing partial response sets; concurrency/timing anomalies in the worker pool under heavy load.

Related errors


AI-assisted analysis of hashicorp/terraform@c9def3e214 (2026-08-07). Data as JSON: /api/errors/8cadcd8926e81a55. Report an issue: GitHub.