AWS Lambda is an event-driven, serverless computing platform. It helps to run code without controlling or managing a server. We can focus on code only. Lambda is an event-driven service it requires some trigger to run the function. If there is any failure in the lambda function, then lambda retries again and runs the code. But sometimes, it is not easy to find the code error. For example, we use nodejs in the AWS lambda function, and on each trigger, the nodejs function runs and is executed successfully. If you look into metric, it shows it as an error. It is an AWS lambda property that if there is an error then it keeps retrying. So even if the function is executed successfully, it is marked as an error lambda keep retry.
There are many ways to handle this. I am adding two ways that I have tried and worked for us.
- AWS Lambda has an option to set the retry attempt. It uses to decide how many times lambda will retry to run the code on error. Go to Lambda, Functions, and then click on the lambda function for that you want to set the retry attempts. In the configuration, open asynchronous invocation and click on edit to set the retry attempts. Set the retry attempts to zero so that it will not run the lambda function multiple times. The disadvantage of this approach is that if there is an error then also lambda will not retry.
- When AWS Lambda runs the function, it passes a context object to the handler.
module.exports.handler = (event, context, callback). One of the properties of the context object is awsRequestId. awsRequestId is used to identify the invocation request and is unique for each invocation. We can save the requestId in the database before the function execution finish. On the next invocation, we can check and verify requestId is the same or not. If the requestId is the same then we can skip it. For example, we save the requestId in the SQL table that has auto-increment id. In the next invocation, we fetch the requestId from the table that has the highest id and check if it is the same as the requestId of the current invocation.
There is one more better way to handle it. I will add that too next time. I am still trying and testing it.
Update: If we add return in the handler function then it will exit process and stop the lambda function too. We are doing async task in the lambda and we use promise to handle that.
module.exports.handler = async (event) => {
const promise = new Promise((resolve, reject) => {
/*
do the async task here. if error use reject and if success then use the resolve
*/
});
return promise;
Once promise is resolved or rejected, node process will exit with success or failure. If it is success then there will be no duplicate invocation.
Top comments (3)
it's better to use the context.awsRequestId or event['requestContext']['requestId'] ?
for more info medium.com/@muralia/how-to-handle-...
event can be of different type. AWS lambda can be triggered from SQS, SNS, API gateway. Depending on what triggered the AWS lambda, event can have the different datas. But context always provide information about invocation, function, and execution environment. So context is more reliable for awsRequestId.
super! for sure it's better, thank you very much