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.