[S-Saranya1]

Motivation and Context

With a multipart-enabled S3AsyncClient, a parallel multipart download could complete with a null response. When part 1 finished, the remaining parts were started before part 1's response was saved. If they all finished first, the download returned null, and S3TransferManager.downloadFile then reported a failure even though every part downloaded. A pause in the same window could also produce a resume token missing part 1.

Modifications

• In ParallelMultipartDownloaderSubscriber, part 1's response and resume context are now recorded before totalPartsFuture completes, which is what starts the remaining parts.
• The part-1 callback now checks once for a single-part object and returns early. Single-part objects behave as before.

Testing

• Added ParallelMultipartDownloaderSubscriberTest. It completes the remaining parts inside part 1's callback, so the race happens on every run.
• The multipart tests run with 2 parts/2 in flight, 4/4 and 4/2. A single-part test confirms that behavior is unchanged.
• The existing S3 multipart download tests and the Transfer Manager unit tests pass.

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Checklist

• I have read the CONTRIBUTING document
• Local run of mvn install succeeds
• My code follows the code style of this project
• My change requires a change to the Javadoc documentation
• I have updated the Javadoc documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed
• I have added a changelog entry. Adding a new entry must be accomplished by running the scripts/new-change script and following the instructions. Commit the new file created by the script in .changes/next-release with your changes.
• My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

• I confirm that this pull request can be released under the Apache 2 license

[jencymaryjoseph]

Could pausing at this point capture part 1 as completed before response and totalParts are available? On resume, would that skip part 1 while leaving totalPartsFuture unresolved, preventing the remaining requests from starting?