SQS short polling broken in SDK v2

[jtorkkola]

Describe the bug

ReceiveMessageInput.WaitTimeSeconds has changed from an integer pointer in SDK v1 to an integer in SDK v2. Previously a nil value meant that a ReceiveMessage call would defer to the queue setting, and a 0 value meant short polling. Now 0 means deferring to the queue setting, and there's no way to short poll if the queue default isn't 0 (see the ReceiveMessageInput serialization logic here).

ReceiveMessageInput.VisibilityTimeout and SendMessageInput.DelaySeconds look to have the same issue.

Expected Behavior

Calling ReceiveMessage with ReceiveMessageInput.WaitTimeSeconds = 0 causes short polling like in SDK v1.

Current Behavior

Calling ReceiveMessage with ReceiveMessageInput.WaitTimeSeconds = 0 defers to the queue's default receive message wait time, which may not be 0.

Reproduction Steps

Call ReceiveMessage with ReceiveMessageInput.WaitTimeSeconds = 0 on an empty queue with a default receive message wait time of 10 seconds, and observe the duration of the call.

Possible Solution

No response

Additional Information/Context

No response

AWS Go SDK V2 Module Versions Used

v1.16.0

Compiler and Version used

1.18

Operating System and version

macOS 12.3.1

[jasdel]

Thanks for reporting this issue @jtorkkola. This looks to be a modeling bug with how the WaitTimeSeconds member is being defined. The v1 SDK assumed everything was nullable, because it didn't have enough information in the model to know differently. The v2 SDK switched to a new modeling IDL which does provide this information, but it looks like this information is wrong in this case.

We'll reach out to the service to identify the correct update, but this most likely will result in the WaitTimeSeconds changing from a value to pointer type. There might be an alternative that we will investigate if possible.

[jtorkkola]

Thanks @jasdel. Could we make sure all the other integers in the SQS input structs get looked at as well? ReceiveMessageInput.VisibilityTimeout and SendMessageInput.DelaySeconds look problematic also, but I didn't comb through everything.

I did take a look at using middleware to mitigate the issue from the user side, but it looks like there's no way to tweak the behavior of the serializer without replacing it entirely.

[calscoo]

Any updates on this? We're migrating our services to the V2 SDK for the new security features, but can't move forward because our service relies on SQS and this bug is holding us up. It hasn't been touched in almost 9 months. @jasdel @vudh1 @RanVaknin

[RanVaknin]

Hi @calscoo, @jtorkkola

Sorry for the long wait.

We have tried getting the SQS team to solve this but they are unable to prioritize this fix.
If you willing, please cut an additional internal ticket to the SQS team via the AWS Console and reference the tracking ticket ID we already have with them P97774845, having a customer directly asking for remediation will help prioritization.

Thanks,
Ran~

[keenangraham]

Running into this with VisibilityTimeout set to 0 in ChangeMessageVisibilityBatch.

Version: github.com/aws/aws-sdk-go-v2/service/sqs v1.31.3

Failed ID: message_0, Code: MissingParameter, Message: The request must contain the parameter ChangeMessageVisibilityBatchRequestEntry.1.VisibilityTimeout.

[RanVaknin]

This is now fixed.

[github-actions]

This issue is now closed.

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.