A progress bar can conceal a missing page of parts
A hypothetical oral-history digitization team is ingesting a large master audio recording into Amazon S3 with multipart upload. A dashboard reports that the first batch of parts exists, and an operator assumes the upload is nearly complete. But the ListParts response covers only a page of data. Amazon S3 documents a maximum of 1,000 returned uploaded parts per ListParts request, and larger uploads may require repeated calls. The practical question is whether the uploaded part numbers and sizes match the intended ingest plan, not whether the first screen looks full.
Start with the exact multipart upload identity
ListParts is scoped to one in-progress multipart upload. It needs a bucket, object key and upload ID originally obtained from the CreateMultipartUpload operation. A key alone is not sufficient: a system may have multiple incomplete uploads for the same object path. Record the upload ID in a restricted ingest ledger with the expected source recording identifier and a start timestamp. Avoid treating a generic bucket listing or an object metadata response as a substitute. ListParts says what has been uploaded for the identified session, not which upload was intended by an operator who lost the ledger.
Read IsTruncated before deciding the inventory is complete
The API returns up to 1,000 parts by default, with max-parts available to request smaller pages. When there are more results, IsTruncated is true and NextPartNumberMarker identifies the continuation point. Send the subsequent request using part-number-marker and the marker returned by S3; continue until the response indicates no more pages. Do not assume part numbers are consecutive or that the number of parts on the last page is a complete expected set. An uploader can retry and replace a part with the same number, while still being in progress.
Reconcile part numbers, sizes and upload intent
Prepare a synthetic manifest describing the intended audio master, expected chunk layout and upload ID. Compare the listed PartNumber values and sizes with the upload plan and mark missing or unexpected entries for investigation. Each returned ETag is metadata about an uploaded part, not a universal full-object integrity certificate. Multipart ETags and checksums have format and algorithm-specific behavior; the proper integrity check depends on the completion request and subsequent object retrieval. The diagram in this article shows illustrative part numbers only. It is not evidence that an actual museum recording was uploaded.
Handle pagination as a stateful audit, not a screenshot
A read-only audit script should keep the bucket, key and upload ID stable across every page while passing through the continuation marker. It should record the request sequence and the final IsTruncated=false state. If a page fails, do not quietly present the current partial array as the final inventory. Use a distinct incomplete status and allow a controlled retry. Because another process can still upload or replace parts while the listing runs, the inventory is a time-bounded observation rather than an immutable snapshot. State that limitation when reporting discrepancies to the ingest team.
Know what ListParts cannot certify
ListParts does not finalize the upload, validate the bytes of the original audio master or guarantee a completed object will be readable. Those are separate steps: CompleteMultipartUpload assembles parts, and after completion the system should verify the object’s expected size, provenance and supported checksum semantics. The API also requires suitable permission to list the parts of the given upload. An AccessDenied response is a permissions signal, not proof that no parts exist. Never publish an audio ingest report that equates a page of part metadata with an independently validated preservation copy.
Distinguish abandoned uploads from active ingest
An upload that has had no activity for days might be abandoned, but an unchanged ListParts result alone does not prove it is safe to abort. Consult the upload coordinator, deployment logs and source-of-truth job ledger before making a destructive decision. AbortMultipartUpload is a separate operation; this guide deliberately stops at read-only inspection. Automated lifecycle cleanup of incomplete multipart uploads has different timing and policy considerations. If there is a legal or preservation obligation, confirm that the original recording still exists in approved storage before allowing any cleanup.
Report page coverage and uncertainty explicitly
A useful audit note includes the bucket alias, key reference, upload ID fingerprint, pages traversed, last marker, observed part count and the observation time. Do not expose secret credentials or private archive identifiers in a public case study. Include a column for expected part count only if the originating ingest plan actually provides one; otherwise state that the expected count is unknown. A zero-result page should trigger a careful look at the upload session and permissions rather than an inference that the content was deleted. Attach the relevant AWS documentation for a future operator.
Close the loop with a preservation verification
Once the uploader’s owner confirms that the part inventory is consistent, completion and full-object verification can proceed in an approved workflow. Compare the archived master’s registered checksum and duration with independently recorded source evidence where available; don’t manufacture a pass percentage. Retain the ingest manifest, the final S3 version or object identifier and the reconciliation outcome. If the upload never completes, mark it as incomplete and escalate rather than calling it a preservation copy. ListParts is a diagnostic lens on the transfer process, not a preservation policy.
How We Research
We consulted named official technical sources on November 11, 2026: Amazon S3 ListParts API reference; AWS CLI s3api list-parts reference; S3 multipart upload overview. We checked the documented parameter or operation, response details, limits and warnings against a narrowly described, hypothetical museum workflow. The examples and diagrams were designed as original instructional material, not based on captured account data. We did not run production tests, access customer archives, measure transfer speeds, confirm permissions on a live site or create genuine vendor screenshots. Check the latest official guides, use synthetic records and require an authorized owner before any production change.
Frequently Asked Questions
The S3 API reference says the response returns at most 1,000 parts; larger results require pagination.
When IsTruncated is true, pass the previous response’s NextPartNumberMarker as part-number-marker.
No. It lists uploaded parts in an in-progress session. Completion and full-object verification are separate.
Yes. Bucket and key alone do not identify the specific multipart upload to inspect.
Only after independent confirmation from the ingest owner and any applicable preservation requirements; ListParts alone cannot decide that.