Thanks for the change. I'd like to understand what issue you faced that this change fixes? I ask because the runtime's (de)serializer is configured to expect the key "eventSourceARN" for the field eventSourceArn.

Using aws-lambda-java-events:2.2.7 with this function:

public class App implements RequestHandler<SQSEvent, Object> {
    public String handleRequest(final SQSEvent input, final Context context) {
        return input.getRecords().get(0).getEventSourceArn();
    }
}

and this payload:

{
  "Records": [
    {
      "messageId": "19dd0b57-b21e-4ac1-bd88-01bbb068cb78",
      "receiptHandle": "MessageReceiptHandle",
      "body": "Hello from SQS!",
      "attributes": {
        "ApproximateReceiveCount": "1",
        "SentTimestamp": "1523232000000",
        "SenderId": "123456789012",
        "ApproximateFirstReceiveTimestamp": "1523232000001"
      },
      "messageAttributes": {},
      "md5OfBody": "7b270e59b47ff90a553787216d55d91d",
      "eventSource": "aws:sqs",
      "eventSourceARN": "arn:{partition}:sqs:{region}:123456789012:MyQueue",
      "awsRegion": "{region}"
    }
  ]
}

I get back: "arn:{partition}:sqs:{region}:123456789012:MyQueue"

@mukhtar what are you using to parse the json message? If using gson, there are issue with case. For example in SQSEvent there is the following private List<SQSMessage> records;. This is not idea since the json that you shared has "Records". This is not very ideal when moving between json parsing libs like gson or moshi.

Hi @srayhunter,

The Lambda service receives json events which sometimes don't meet the normal Java naming conventions. To handle this custom serialization is done on the customers behalf. You can find the implementation in the serialization module.

In order to unit test Lambda function handlers we advise that you use the Testing module in order to have this custom serialization exercised.