Fix Apache5 HTTP client retry failures with non-resettable streams

[joviegas]

Motivation and Context

When using S3Client with Apache5 HTTP client, PutObject/GetObject requests fail immediately with the following error:

java.lang.RuntimeException: Could not create new stream:
at software.amazon.awssdk.http.auth.aws.internal.signer.io.ResettableContentStreamProvider.newStream(ResettableContentStreamProvider.java:38)
...
Caused by: java.io.IOException: mark/reset not supported

Root Cause:

• RepeatableInputStreamRequestEntity constructor calls getContent() which triggers ContentStreamProvider.newStream()
• ResettableContentStreamProvider.newStream() attempts to reset the stream before returning it
• The underlying stream doesn't support mark/reset operations, causing immediate failure
• This happens during request preparation, before any retry attempts

Modifications

Added EntityCreationResult helper class

• Captures both the InputStreamEntity and content stream during creation
• Avoids calling getContent() which would trigger ContentStreamProvider.newStream() and cause the reset failure
• Ensures we use the original stream instance without triggering resets

Stored content stream reference as a field

• Prevents multiple ContentStreamProvider.newStream() calls
• Avoids triggering stream reset operations during entity lifecycle

Fixed resource management

• Removed manual stream closing to prevent double-closing
• InputStreamEntity properly handles stream lifecycle

Testing

• Added Junits
• Tested S3 Integ and Junits , all passed with Apache5.x upgrade

License

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

[sonarqubecloud]

Quality Gate failed

Failed conditions
64.1% Coverage on New Code (required ≥ 80%)
21.2% Duplication on New Code (required ≤ 3%)
C Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[Fred1155]

Hi just trying to understand, in this circumstance, is it equivalent to create an Entity with InputStream with zero length?

[joviegas]

Yeap , that is done here

aws-sdk-java-v2/http-clients/apache5-client/src/main/java/software/amazon/awssdk/http/apache5/internal/RepeatableInputStreamRequestEntity.java

Lines 151 to 154 in 0bdf878

	private static InputStream getContent(Optional<ContentStreamProvider> contentStreamProvider) {
	return contentStreamProvider.map(ContentStreamProvider::newStream)
	.orElseGet(() -> new ByteArrayInputStream(new byte[0]));
	}

[Fred1155]

Should we add tests for concurrent access scenarios to ensure concurrent access to writeTo method is safe, or that has already been covered in other places?

[RanVaknin]

I think the reason why writeTo_ConcurrentWrites_HandlesCorrectly was removed is because concurrent reads from an inputStream is not thread safe?

[joviegas]

Yes, concurrent reads from an InputStream are not thread-safe, and if we need to implement this functionality, we would need to add proper synchronization mechanisms. Since the Apache 4.x client doesn't have support for this, I removed this test case.
Note that I added this test case in my previous PR where I included several test cases to RepeatableInputStreamRequestEntityTest to verify all possible scenarios in both 4.x and 5.x versions to ensure consistent functionality. However, at that time, I didn't test for flakiness by running it in loop mode. When I later ran it as a @Repeated test for 1000 iterations, it started failing.
So initially I thought it was fine doing concurrent access for Apache 4.x since it was passing (it fails intermittently )