-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SQS receive_message VisibilityTimeout attribute not returned #4272
Comments
Hi @LuchiLucs, thanks for reaching out. Testing from my side, having "All" as a value and pulling the message from the SQS for the first time by a consumer, the output will show the values for "MessageSystemAttributeNames". When pulling the same message right after you have pulled it, it may not show the list of attributes. This is because the message that you have pulled previously have been taken out already from the SQS Queue and already been delivered to a consumer. This is also shown on the visibility timeout documentation ( https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html ). That said, please try to create a new message then try to pull the message from SQS for the first time with "All" as a value and see the results. If VisibilityTimeout is not specified, it has a 30 seconds default value. So the longer the VisibilityTimeout, the longer the message will not be retrieved again. If you would like to get the same message again right away, you can set a low "VisibilityTimeout" (VisibilityTimeout=0) - this way you would be able to get the output for the parameters you have included. Also, please take note that "VisibilityTimeout" would not be a value for "MessageSystemAttributeNames". I have raised an internal ticket to our SQS Documentation team for clarifying the retention of outputs and for the VisibilityTimeout to be added to the API docs. If you have any questions, please do let me know. For other review, please provide full debug logs by adding |
@adev-code Thank you for your review. I'm confused whether I should be able to see the set custom value of the key |
Hi @LuchiLucs, thanks for the update. As per the documentation for receive_message (https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/sqs/client/receive_message.html#SQS.Client.receive_message), the 'VisibilityTimeout' is not part of the response. It is only used as an input to configure the VisibilityTimeout. I have submitted a feature request to the SQS Team about if this can be added to the response. Please refer to an SDK changelog (https://raw.githubusercontent.com/boto/boto3/develop/CHANGELOG.rst) for updates about this going forward. Please let me know if you have any other questions. Thanks! |
Greetings! It looks like this issue hasn’t been active in longer than five days. We encourage you to check if this is still an issue in the latest release. In the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please feel free to provide a comment or upvote with a reaction on the initial post to prevent automatic closure. If the issue is already closed, please feel free to open a new one. |
Describe the bug
Calling the
receive_message()
method of the SQS client withMessageSystemAttributeNames
key and value["All", "VisibilityTimeout"]
or["All"]
seems not to return a response whose message attribute contains the intented key under its attributes.Moreover the Python SDK documentation here has that key in the deprecated key
AttributeNames
and not inMessageSystemAttributeNames
. The REST API is here.Assuming each message has a custom visibility timeout already set. How should I retrieve this information?
Expected Behavior
The returned response should contain the specified attribute.
Current Behavior
The returned response seems not to contain the specified attribute.
Reproduction Steps
Possible Solution
No response
Additional Information/Context
No response
SDK version used
1.35.2
Environment details (OS name and version, etc.)
Linux (AWS EC2)
The text was updated successfully, but these errors were encountered: