Introduction
The ability of AWS Lambda to integrate seamlessly with your favorite operational tools and services is one of its most appealing features. As a result, developers can construct spectacular cloud infrastructures, but they sometimes have trouble managing lambda function errors. As a result, this can lead to application downtime. Thankfully in this blog, we will go through how to properly handle function errors as we cover the following items:
- What is a lambda function error?
- How to gracefully handle a lambda function error
- Building a solution
What is a Lambda function error?
A lambda function error is when your function’s code throws an exception or returns an error object [1]. What are some possible causes for a function error? Imagine this scenario: you have a Lambda integration with Stripe to process payments. Your lambda function got invoked and sent a payment request to Stripe, but the request failed because Stripe’s service is down. While Stripe is quite reliable, this is just an example.

How to gracefully handle a Lambda function error?
One approach to handling a lambda function error is using Amazon Simple Queue Service (SQS). In the scenario described earlier, a queue would sit in-between Stripe and the Lambda function. If the Stripe service fails, SQS will store the failed messages in a dead-letter queue using a re-drive policy. This mechanism allows Lambda to re-process failed jobs. Isn’t that cool?

Building the solution
Init Serverless Framework
We will use the Serverless Framework tool to build our infrastructure. The below commands create a Serverless AWS NodeJs template app.
Configure AWS Credentials
Paste the following code into the '.env' file. Enter your personal AWS Access Key ID & Secret Access Key.
Define Resources
- Standard Queue
- Dead-Letter Queue
- Lambda Function
Paste the following code into the 'serverless.yml' file. The 'deadLetterTargetArn' is a reference to a dead letter queue where failed jobs will be stored. If a job failed and the receive count for a message exceeds the 'maxReceiveCount', Amazon SQS moves the message to the dead-letter-queue.
Create code for Lambda
The function code is pretty basic. We are simulating a Stripe payment request/response. It simply reads a message from the queue and runs a conditional check. The function will throw an error if the message content is 'PYMT_FAILED'. Otherwise, if the message content is 'PYMT_SUCCEED' the function will run as normal and return a successful response.
Paste the following code into the 'handler.js' file.
Deploy Infrastructure
Once the stack is successfully deployed, you can go to CloudFormation in the AWS console and retrieve the URL for the Source Queue and the Dead Letter Queue.

Sending Messages to the Queue
We are simulating the process of sending a Stripe failed payment response. For the queue URL, enter the Source Queue URL:
Inspect Lambda Function Logs
Now, if we inspect the logs for the lambda function, we can see the function threw an error.

Inspect Dead-Letter Queue
Paste the following command in your terminal:
The command displays the failed message that is stored in the dead-letter queue.
Start a Re-drive
Currently, I am not aware if there is a process to trigger a queue re-drive programmatically. Great opportunity to let AWS know this feature is highly needed. We can start the re-drive using the AWS Console. Head over to the AWS Console and search for SQS and select the Dead-Letter Queue we created earlier. Starting a re-drive will submit the message to the original source queue and trigger the lambda function to re-process the message.

Conclusion
In this article, you have seen what a Lambda Function error is and one approach to properly handling the error using a dead-letter queue. As a next step, you can extend the architecture further by adding alarms for when the queue has reached its maximum re-drive policy.
You can find the complete source code on my GitHub.
For any questions, comments, or concerns, please feel free to message me on LinkedIn or Twitter.
Happy building & have a great day!
References
[1] : https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html