SQS returns uncapitalized dataType, stringValue, but Boto3 requires capitalization

When using SQS as a Lambda trigger, the MessageAttributes return values with “dataType” and “stringValue”, starting with lower case letters. When trying to send to an SQS queue, Boto3 requires capitalized “DataType” and “StringValue” to be part of the messageAttributes.

This is confusing and I think should be altered, as it looks odd to capitalize differently depending on whether you are sending or receiving a message.

Example: Sent the following to SQS queue

'messageAttributes': {
        'startTime': {
          'StringValue': '20190929T000000',
          'DataType': 'String'
        },
        'endTime': {
          'StringValue': '20191006T000000',
          'DataType': 'String'
        },

Received the following in the Lambda event

'messageAttributes': {
        'startTime': {
          'stringValue': '20190929T000000',
          'stringListValues': [],
          'binaryListValues': [],
          'dataType': 'String'
        },
        'endTime': {
          'stringValue': '20191006T000000',
          'stringListValues': [],
          'binaryListValues': [],
          'dataType': 'String'
        },

[swetashre]

@Tylermarques - Thank you for providing me the steps to reproduce the issue. Now i am able to reproduce the issue. This is because lambda process the event in different way than the service SQS. I have internally escalated this issue to the service team. I will post here when i get any update.

[vfilimonov]

Hello @swetashre

The example is actually trivial. Put it in a newly created lambda function, add SQS permissions and connect to some SQS feed.

import json

def lambda_handler(event, context):
    print(json.dumps(event, indent=2).replace('\n', '\t'))
    return dict(event)

Upon adding the message in the SQS - check the CloudWatch logs. You’ll see the event as it is received by lambda - non-capitalized:

{
    "Records": [
        {
            "messageId": "...",
            "receiptHandle": "...",
            "body": "hello there",
            "attributes": {
                "ApproximateReceiveCount": "1",
                "SentTimestamp": "1578907121082",
                "SequenceNumber": "...",
                "MessageGroupId": "lambdas",
                "SenderId": "...",
                "MessageDeduplicationId": "...",
                "ApproximateFirstReceiveTimestamp": "1578907121082"
            },
            "messageAttributes": {
                "Name": {
                    "stringValue": "SQS-test",
                    "stringListValues": [],
                    "binaryListValues": [],
                    "dataType": "String"
                }
            },
            "md5OfMessageAttributes": "",
            "md5OfBody": "...",
            "eventSource": "aws:sqs",
            "eventSourceARN": "...",
            "awsRegion": ""
        }
    ]
}

Note:

1. Records -> messageAttributes -> Name -> stringValue (and as you’ve seen, Boto3 function “receive_message” would return StringValue)
2. Records -> messageId (and Boto3 would return MessageId)
3. The structure is called Records (and Boto3 would return Messages)

All of these inconsitencies make it quite problematic to develop code which works with both boto3-responses and the direct responses from AWS.