An unfinished transfer is not an archived object
A collections department might ingest thousands of digitized oral-history files into S3. Some multipart transfers stall because a client disconnects before completion. ListMultipartUploads identifies multipart uploads that were initiated but have not been completed or aborted. It is a bucket-level inventory of upload sessions, not a listing of object versions or a confirmation that the archive contains a complete file. A session can still be active, so an old-looking upload is not automatically safe to cancel. Build an inventory first, reconcile it with the ingest application and obtain a retention or recovery decision before applying any cleanup operation.
Distinguish ListMultipartUploads from ListParts
The operation ListMultipartUploads discovers the in-progress upload sessions across a bucket; each result can identify a key and upload ID. ListParts answers a different question: which parts exist for a specific key and upload ID. A previous archive workflow might already use ListParts to diagnose one transfer. That does not produce a complete inventory of all abandoned sessions. In a two-stage investigation, first enumerate upload sessions, then inspect parts only for particular sessions that need diagnosis. Neither operation automatically completes an upload, checks the content of a finished object or verifies the legal right to discard a derivative.
Page through more than 1,000 uploads safely
S3 lists no more than 1,000 in-progress multipart uploads in one ListMultipartUploads response. When IsTruncated is true, general-purpose buckets return NextKeyMarker and NextUploadIdMarker. Supply both markers in the following request to continue. Do not advance using the last object name from a rendered dashboard or a guessed numeric offset. Keep the same bucket, prefix, permissions and request context during enumeration. The AWS documentation also notes special marker behavior for directory buckets, so do not blindly reuse general-purpose bucket pagination logic across every bucket type. A saved partial page is evidence of a partial inventory, not the final count.
Understand directory-bucket differences
For directory buckets, AWS documents that upload-id-marker and NextUploadIdMarker are not supported; continue using the returned key marker. Directory buckets also have special prefix constraints. An inventory tool should identify the bucket type and apply the documented marker rules before claiming that a traversal is complete. If the script cannot determine how to continue, stop and report an incomplete scan rather than silently dropping records. Do not hard-code one page size as a guarantee of total coverage. Store the page count and continuation state in a restricted run log so a later operator can see where the inventory ended.
Build a reconciliation table from the returned fields
Create a minimal review table containing bucket scope, object key, upload ID, initiated timestamp, initiator identity where appropriate and the current ingest-job reference. The object key may contain sensitive collection labels, so restrict who can read the report and avoid using raw keys in public dashboards. Treat the initiated timestamp as a hint, not proof that an upload is abandoned. Check ingest worker activity, pending retries and whether the same item has a later successful version. If a transfer was started by a temporary credential that has since expired, record that uncertainty instead of assuming it can never complete.
Keep the inventory and cleanup decision separate
A first pass can classify uploads as recently active, needing investigation or approved for termination. A second authorized operation can call AbortMultipartUpload for an approved key and upload ID when appropriate. Aborting is not equivalent to deleting an already completed object, and it should not be an automatic consequence of seeing an old timestamp. AWS warns that in-flight parts may still finish after an abort request; verifying released storage may require additional checks or repeated aborts in some conditions. Review the current documentation and test the application’s retry behavior before bulk cleanup.
Compare one page with a complete traversal
Imagine a synthetic bucket containing more sessions than fit on one response page. A dashboard displaying only page one might miss unfinished transfers for a later accession range. A complete inventory preserves continuation markers, iterates to IsTruncated=false and records the scope. A directory-bucket branch uses its own supported continuation rule. The comparison graphic illustrates the difference between a first page, a correctly continued listing and a partially failed scan. These are invented example states; no live bucket was queried and no actual byte savings were measured.
Do not confuse costs with authorization
Orphaned multipart parts can consume storage while a session remains incomplete, but a cost concern does not by itself authorize destroying preservation data. Apply the museum’s preservation policy, litigation holds and workflow owner approval before aborting anything. Different bucket settings, IAM controls and possible lifecycle rules may affect how sessions are handled. Confirm the caller has only the permissions needed for inventory and that a separate, reviewed role performs destructive cleanup. A list request is read-only; the moment an operator moves to abort, the safety and audit requirements change.
Reconcile a cleanup attempt with ingest evidence
After an approved cleanup, inspect a new inventory and the ingestion application’s state for the same key and upload ID. A missing upload session does not prove that the intended master object was preserved. Verify the completed archive object separately, including its version and integrity procedure if applicable. For failed or ambiguous operations, do not repeat destructive actions automatically: review the recorded response and current state first. Keep a clear chronology of listing pages, human approvals and any subsequent aborts. That chronology matters for museum evidence handling just as much as the immediate storage charge.
Run the audit without claiming a live recovery
Use a nonproduction bucket with simulated incomplete uploads to verify marker handling, duplicate keys and pagination stops. Add tests for general-purpose versus directory-bucket behavior and failure after an intermediate page. Do not call the scan complete if IsTruncated remains true or continuation data were lost. The primary sources are the AWS ListMultipartUploads and AbortMultipartUpload API references. This guide offers a documentation-based workflow, not evidence that we accessed an AWS account, inspected a collection archive or completed a cleanup. Treat its drawings as conceptual inventory examples rather than storage console screenshots.
How We Research
For this November 11, 2026 documentation-based review, we consulted Amazon S3 ListMultipartUploads API; Amazon S3 AbortMultipartUpload API. We checked the named API fields, scope, failure paths and relevant limitations against a hypothetical museum workflow, and compared operations with nearby endpoints when that distinction affected safe use. We did not access any private account, issue destructive API calls, run a CI job, inspect actual source content or make benchmark measurements. The artwork consists of original schematic illustrations rather than captured vendor interfaces. Before applying an operational change, confirm the latest official documentation, verify the target account and resource identifiers, and obtain the required organizational approvals.
Frequently Asked Questions
No. It lists multipart upload sessions that have been initiated but not completed or aborted.
One response can contain at most 1,000 uploads. Continue with the documented markers while IsTruncated is true.
No. The S3 API documents that directory buckets use key-marker continuation and do not support upload-id-marker.
No. Reconcile its activity, ingest job and preservation requirements, then obtain the appropriate authorization.
ListParts examines parts of one specified multipart upload. ListMultipartUploads finds in-progress upload sessions across the bucket.