Handling Asynchronous Errors with Dead Letters
In this lesson, you will learn how to handle asynchronous errors with dead letters by modifying the template file.
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 ...