Fix issue where the Scheduled Timeout was incorrectly completing the futures with empty messages

[joviegas]

Motivation and Context

The key modification was ensuring that the same future passed to receiveQueueBuffer.receiveMessage is the one that gets completed, regardless of whether a timeout occurs.

Previously, a new future (timeoutFuture) was scheduled to complete after the timeout period, but this future was independent of the one added to the futures queue. Now, instead of creating a new timeout future, we directly complete the original future (receiveMessageFuture) if it hasn't already been completed before the timeout occurs.

Root Cause

The issue occurred because a new CompletableFuture (timeout future) was being created and completed during timeouts, rather than completing the original future added to the ReceiveBuffer. This left the original future uncompleted, causing the buffer to return empty responses.

Fix

The fix ensures that the same receiveMessageFuturepassed to the buffer is completed, even when a timeout occurs. The timeout logic now checks if the original future is complete and directly completes it, avoiding the creation of a separate timeout future. This ensures that the buffer behaves correctly and returns the expected messages.

Modifications

The key modification was ensuring that the same future passed to receiveQueueBuffer.receiveMessage is the one that gets completed, regardless of whether a timeout occurs.

Previously, a new future (timeoutFuture) was scheduled to complete after the timeout period, but this future was independent of the one added to the futures queue. Now, instead of creating a new timeout future, we directly complete the original future (receiveMessageFuture) if it hasn't already been completed before the timeout occurs.

• Also we need to honor the user passed waitReceiveTime as the timeoOut time , same as done in V1 , thus removed bypassing .

Testing

• Integ test
• Junits added

License

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

[zoewangg]

I don't think we need to check isDone here, complete will handle it.

[joviegas]

Done

[zoewangg]

Why are we removing this?

[joviegas]

If the user passes this value then user can control the Polling time out , this is behaviour same as https://github.com/aws/aws-sdk-java/blob/61d73631fac8535ad70666bbce9e70a1d2cea2ca/aws-java-sdk-sqs/src/main/java/com/amazonaws/services/sqs/buffered/ReceiveQueueBuffer.java#L192-L197

I removed this in earlier PR but when I was doing V1 comparison I realized that V1 uses this value to determine the Client side Wait time for that particular request.

[joviegas]

We already supported in V2

aws-sdk-java-v2/services/sqs/src/main/java/software/amazon/awssdk/services/sqs/internal/batchmanager/QueueAttributesManager.java

Lines 76 to 82 in dd9379d

	Integer waitTimeSeconds = rq.waitTimeSeconds();
	if (waitTimeSeconds != null) {
	long waitTimeMillis = TimeUnit.SECONDS.toMillis(waitTimeSeconds);
	return CompletableFuture.completedFuture(Duration.ofMillis(Math.max(configuredWaitTime.toMillis(), waitTimeMillis)));
	}
	CompletableFuture<Map<QueueAttributeName, String>> attributeFuture = getAttributeMap();

But after handling the Surface API review comments where I added a check to bypass, I went ahead and added check to this since it was an additional Attribute related to long polling but when used with Automatic Batch manager we use it client side polling time so thus we need this to go through the batch manager

[sonarqubecloud]

Quality Gate failed

Failed conditions
B Reliability Rating on New Code (required ≥ A)

See analysis details on SonarCloud

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