Handling Asynchronous Errors with Dead Letters
Explore how AWS Lambda handles asynchronous errors through automatic retries and the use of dead letter queues. Understand configuring retry limits, using SNS and SQS for error notifications, and setting up custom error processing. This lesson equips you with techniques to manage failed asynchronous events efficiently in serverless applications.
We'll cover the following...
With synchronous calls, errors can be reported directly back to the caller, and the caller can then decide whether it’s worth retrying or not. With asynchronous calls, the caller can’t do that, because it is not waiting on results.
The good news is that to protect you against intermittent network problems or transient infrastructure issues, Lambda will automatically retry twice. AWS does not publish any official documentation on the duration between retries, but experience shows that the first retry will happen almost immediately after an error. If the function fails to process the event again, the second retry will happen about a minute later. Keep watching the logs while Lambda refuses to copy a file that’s not an image, and you’ll see the retries.
Asynchronous request IDs and retries #
If Lambda retries processing an event, it will send the same request ID as in the original attempt. You can use the request ID to check for any partial results if your Lambda works in multiple stages, and then just partially re-process the event. This is another reason why it’s good to use request IDs to generate resource references.
If the second retry fails as well, Lambda gives up on processing the event, concluding that the error is in the code rather than the infrastructure, or that the infrastructure has not ...