vector: aws_s3 source: async receive_messages does not return after poll_secs

A note for the community

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Problem

when using aws_s3 source, the sqs client’s receive_messages fn sometimes hangs with no return value. this causes vector to stop polling from sqs (loop still waiting for a future to end before requesting again)

Configuration

sources:
  s3:
    auth:
      assume_role: ${S3_RO_ROLE}
      region: ${S3_REGION}
    region: ${S3_REGION}
    sqs:
      queue_url: ${SQS_QUEUE_URL}
    type: aws_s3

Version

0.27.0 -> 0.37.0

Debug Output

No response

Example Data

No response

Additional Context

I have made a fork with a PR that sets a timeout on the receive_messages fn, It’s probably not the best way to handle it but it’s working. It’s possible that updating the SDK might help, I wasn’t able to update it though.

References

https://discord.com/channels/742820443487993987/1019686524742271038/threads/1214559445963505734

About this issue

Original URL
State: open
Created 4 months ago
Reactions: 3
Comments: 21 (8 by maintainers)

Most upvoted comments

If you only need the timeout for SQS long polling, then I recommend only setting it for that specific operation in the operation’s config override. It’s pretty difficult to come up with an operation timeout value that works across different AWS services, since some operations are expected to take longer than others (for example, downloading a large file from S3).

jdisanti on Mar 14, 2024

OK, so request.{connect,read}_timeout_seconds and request.aws.operation_{attempt_,}timeout_seconds} then? And should we have the optional IMDS settings default to these if not configured? I’m happy to attempt the necessary changes.

That all sounds right to me! Agreed with having the IMDS fallback to those.

jszwedko on Mar 13, 2024