I have a basic SQS Queue triggering Lambda with a redrive policy to send failed messages to DLQ after 5 retries. I read that Lambda should add message attributes about the error to the message
Everything works as expected except when I look at the message in the DLQ I don't see any ErrorCode, ErrorMessage attributes from Lambda. Has anyone got this to work?
You are confusing the behavior of two different features.
An SQS queue can have a dead letter queue.
When the
ReceiveCountfor a message exceeds themaxReceiveCountfor a queue, Amazon SQS moves the message to a dead-letter queue (with its original message ID).
A Lambda function can also have a dead letter queue.
Any Lambda function invoked asynchronously is retried twice before the event is discarded. If the retries fail and you're unsure why, use Dead Letter Queues (DLQ) to direct unprocessed events to an Amazon SQS queue or an Amazon SNS topic to analyze the failure.
...
The payload written to the DLQ target ARN is the original event payload with no modifications to the message body. The attributes of the message contain information to help you understand why the event wasn’t processed
What you have is the former -- an SQS queue with a DLQ, not the latter -- a Lambda function with a DLQ.
In your configuration, messages are simply moved to the DLQ as described, without modification, according to the redrive policy.
It isn't possible to receive the messages you are looking for, in a DLQ on a Lambda function that is listening to an SQS queue, because SQS/Lambda integration is does not use asynchronous function invocations.
Lambda polls the queue and invokes your function synchronously with an event that contains queue messages.
The SQS/Lambda integration can't be configured otherwise, and configuring the Lambda function itself with a DLQ (instead of the SQS queue) will have no effect.
The workaround is to use the CloudWatch logs for your Lambda function to find the problematic messages. Log the SQS MessageId in your code, so you can find it in the logs, later.
