Multipart upload separates staging from publication

Initiating an upload returns an upload ID associated with the destination bucket and key. Parts are uploaded under that ID with part numbers, and the client records the returned information required for completion. A later upload of the same part number replaces that part's staged content for the upload rather than appending a second logical part. Keep the intended part list and its validators in durable client state when recovery needs to survive a process restart.

Completion assembles the specified parts in the API's part-number ordering and creates the object after successful processing. The client must supply the correct complete list rather than assuming every previously attempted transfer is present. Part sizes and counts have API limits, including special handling of the final part, so choose chunking within the documented contract. Parallelism improves transfer utilization only up to the actual network, memory, and service limits; allocating an unbounded number of part buffers creates a new failure mode.

Amazon S3 documents that CompleteMultipartUpload can send an initial HTTP 200 header while processing continues, then return an error inside the response body. A raw client that treats the header as final success can publish a manifest referring to an object whose upload did not complete. Consume and parse the full response according to the API, or use a supported SDK whose error handling covers that case. Whitespace while waiting is not a completed object result.

A lost connection after sending completion creates an ambiguous observation: the client may not know whether publication happened. Reconcile using the API's documented state and object evidence, preserving the upload identity and intended object properties. Blindly starting a new unconditional upload can replace another writer's object or create an extra version. Conditional completion, version-aware checks, and application operation identifiers can constrain that recovery, but the exact error-specific retry behavior must follow the service contract rather than a universal retry-everything rule.

Incomplete uploads can retain parts and incur storage usage until they are completed or removed. Stop or join concurrent part transfers before cleanup where the client design permits it. S3 documents that in-flight part operations may still succeed around an abort and that repeated abort action can be needed to release all retained parts. Use the documented listing and cleanup checks rather than assuming a single returned abort header proves no staged bytes remain. Lifecycle cleanup of incomplete uploads is a separate backstop, not proof that the client recovered its own state.

The queue lab visualizes a normalized backlog of abandoned-upload cleanup work. Reset, set both λ=3 and μ=2, predict growth from four initial items, then Play or Step. For a separate case, Reset and set both λ=2,μ=3 before predicting drainage. Editing pauses but retains elapsed time and recomputes the fixed-rate model from its initial four. This is not a multipart state machine or a byte-occupancy estimator: uploads have different sizes, part races, and completion outcomes that the lab does not represent.