aws-sqs-sdk: receive_messages is flaky regarding timeout (at wait_time_seconds)

[AvihaiSam]

Describe the bug

running vector (vector.dev) with aws_s3 source (through sqs) uses aws-sqs-sdk to poll for new messages.
It uses loop with their run_once() implementation which calls SDK's receive_messages

When running long enough - it has been noticed that there's not alway a timeout on receive_messages method even though wait_time_seconds is configured properly, and the async function hangs waiting.

Expected Behavior

wait_time_seconds must be honored.

Current Behavior

most of the time, there's no problem, because answer is returned on time, but when it doesn't return - there's no timeout and it hangs...

Reproduction Steps

run

loop {
  _ = sqs_client
            .receive_message()
            .queue_url("some-url")
            .max_number_of_messages(10)
            .visibility_timeout(30)
            .wait_time_seconds(15)
            .send()
            .map_ok(|res| res.messages.unwrap_or_default()) => {}
}

Possible Solution

No response

Additional Information/Context

vectordotdev/vector#20017

Version

vector uses sqs-sdk 1.3.0, but didn't see any big difference with latest

Environment details (OS name and version, etc.)

x86

Logs

No response

[jdisanti]

I recommend setting an operation_attempt_timeout on the timeout config either as a client-level config when you create the client (if this is the only operation you use it for), or using the config_override() function before calling send(). This timeout should be a little bit longer than the wait_time_seconds given to the ReceiveMessage call.

I think there generally needs to be a better solution for default timeouts in the SDKs, but this hasn't been tackled yet.

[jmklix]

You can use the settings @jdisanti recommended above. We don't currently have any plans to change the default timeouts. Closing this issue

[github-actions]

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.