Skip to main content

CompleteMultipartUpload

Contributors netapp-pcarriga netapp-lhalbert
PDFs

The CompleteMultipartUpload operation completes a multipart upload of an object by assembling the previously uploaded parts.

Note StorageGRID supports non-consecutive values in ascending order for the partNumber request parameter with CompleteMultipartUpload. The parameter can start with any value.

Resolve conflicts

Conflicting client requests, such as two clients writing to the same key, are resolved on a "latest-wins" basis. The timing for the "latest-wins" evaluation is based on when the StorageGRID system completes a given request, and not on when S3 clients begin an operation.

Supported request headers

The following request headers are supported:

  • x-amz-checksum-sha256

  • x-amz-storage-class

    The x-amz-storage-class header affects how many object copies StorageGRID creates if the matching ILM rule specifies the Dual commit or Balanced ingest option.

  • STANDARD

    (Default) Specifies a dual-commit ingest operation when the ILM rule uses the Dual commit option, or when the Balanced option falls back to creating interim copies.

  • REDUCED_REDUNDANCY

    Specifies a single-commit ingest operation when the ILM rule uses the Dual commit option, or when the Balanced option falls back to creating interim copies.

    Note If you are ingesting an object into a bucket with S3 Object Lock enabled, the REDUCED_REDUNDANCY option is ignored. If you are ingesting an object into a legacy Compliant bucket, the REDUCED_REDUNDANCY option returns an error. StorageGRID will always perform a dual-commit ingest to ensure that compliance requirements are satisfied.
Caution If a multipart upload is not completed within 15 days, the operation is marked as inactive and all associated data is deleted from the system.
Note The ETag value returned is not an MD5 sum of the data, but follows the Amazon S3 API implementation of the ETag value for multipart objects.

Unsupported request headers

The following request headers aren't supported:

  • x-amz-sdk-checksum-algorithm

  • x-amz-trailer

Versioning

This operation completes a multipart upload. If versioning is enabled for a bucket, the object version is created after completion of the multipart upload.

If versioning is enabled for a bucket, a unique versionId is automatically generated for the version of the object being stored. This versionId is also returned in the response using the x-amz-version-id response header.

If versioning is suspended, the object version is stored with a null versionId and if a null version already exists it will be overwritten.

Note When versioning is enabled for a bucket, completing a multipart upload always creates a new version, even if there are concurrent multipart uploads completed on the same object key. When versioning is not enabled for a bucket, it is possible to initiate a multipart upload and then have another multipart upload initiate and complete first on the same object key. On non-versioned buckets, the multipart upload that completes last takes precedence.

Failed replication, notification, or metadata notification

If the bucket where the multipart upload occurs is configured for a platform service, multipart upload succeeds even if the associated replication or notification action fails.

A tenant can trigger the failed replication or notification by updating the object's metadata or tags. A tenant can resubmit the existing values to avoid making unwanted changes.

Refer to Troubleshoot platform services.