SQS ReceiveMessageRequest accepts invalid QueueAttributeName as attribute names
Describe the bug
This bug appears both in the Java SDK as well in the API docs.
The SQS ReceiveMessage API request allows you to specify attribute names AttributeName.N to include in the response. The API docs contain a correct list of possible values; being:
- All – Returns all values.
- ApproximateFirstReceiveTimestamp – Returns the time the message was first received from the queue (epoch time in milliseconds).
- ApproximateReceiveCount – Returns the number of times a message has been received across all queues but not deleted.
- AWSTraceHeader – Returns the AWS X-Ray trace header string.
- SenderId
- For an IAM user, returns the IAM user ID, for example ABCDEFGHI1JKLMNOPQ23R.
- For an IAM role, returns the IAM role ID, for example ABCDE1F2GH3I4JK5LMNOP:i-a123b456.
- SentTimestamp – Returns the time the message was sent to the queue (epoch time in milliseconds).
- MessageDeduplicationId – Returns the value provided by the producer that calls the SendMessage action.
- MessageGroupId – Returns the value provided by the producer that calls the SendMessage action. Messages with the same MessageGroupId are returned in sequence.
- SequenceNumber – Returns the value provided by Amazon SQS.
However, it also describes an incorrect list of possible values:
Valid Values: All | Policy | VisibilityTimeout | MaximumMessageSize | MessageRetentionPeriod | ApproximateNumberOfMessages | ApproximateNumberOfMessagesNotVisible | CreatedTimestamp | LastModifiedTimestamp | QueueArn | ApproximateNumberOfMessagesDelayed | DelaySeconds | ReceiveMessageWaitTimeSeconds | RedrivePolicy | FifoQueue | ContentBasedDeduplication | KmsMasterKeyId | KmsDataKeyReusePeriodSeconds
I tihnk this list of values is wrong. The values originate from the Queue attribute names; not the Message attribute names.
Source: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html#API_ReceiveMessage_RequestParameters
The Java API looks like this:
public ReceiveMessageRequest withAttributeNames(QueueAttributeName... attributeNames)
The QueueAttributeName enum values are invalid for this API request.
Expected Behavior
Both the API docs and Java SDK should not mention QueueAttributeNames as possible values for the ReceiveMessageRequest's attribute names.
Instead it would be nice to have a MessageAttributeName enum containing the valid attribute names.
Current Behavior
The invalid queue attribute names are ignored by the API.
Steps to Reproduce
No reproduction needed as this is only a documentation/API spec issue.
Possible Solution
Correct the API spec to reflect the actual behavior of the SQS API.
Context
I was suprised when I read the documentation that I could request the ApproximateNumberOfMessages attribute when requesting a message form SQS. As it turned out, that wasn't possible. The contradictory description in the API reference made me conclude this is a bug in the API docs and SDK.
Your Environment
- AWS Java SDK version used: 1.11.762
- JDK version used: Not relevant
- Operating System and version: Not relevant
Link to code: https://github.com/aws/aws-sdk-java/blob/7b1e5b87b0bf03456df9e77716b14731adf9a7a7/aws-java-sdk-sqs/src/main/java/com/amazonaws/services/sqs/model/ReceiveMessageRequest.java#L1063
@vanDonselaar thank you for reporting this. QueueAttributeName is not the correct enum for AttributeNames in ReceiveMessage, it should be MessageSystemAttributeName instead.
The correction need to be made upstream in the model owned by the SQS team, I'll contact them internally and ask for the fix. Will update when we hear back.
Any update on this? Or suggested workarounds beyond needing to request All?
@lnavarette: you can convert MessageSystemAttributeName values to strings via toString and pass them to attributeNamesWithStrings
No updates here, other than the SQS team is aware of the issue. I'll go ahead and close this issue, please track updates here: https://github.com/aws/aws-sdk/issues/233.
COMMENT VISIBILITY WARNING
Comments on closed issues are hard for our team to see. If you need more assistance, please 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.