‫Okay. So I have my demo-lambda function
‫that I want to invoke asynchronously this time.
‫So if we look at the code again,
‫it will print some values
‫then it will return the event key1.
‫But if we invoke this asynchronously,
‫we cannot do it from the console,
‫we have to do it from the CLA.
‫So let's open CloudShell.
‫And so the whole purpose of an asynchronous invocation
‫is that we do not have the results back to us.
‫So let's copy this entire command right here.
‫So I paste a command and press enter.
‫And my lambda function has now been invoked,
‫and we get a status code 202 as a result.
‫So that means that the lambda function
‫has been successfully invoked
‫but we don't know the results.
‫And so to look at the result what we could do
‫is we look at the CloudWatch logs.
‫So if you go under monitor and look at the CloudWatch logs
‫we can look at the recent invocations.
‫And then if we look at
‫one that will appear very soon hopefully.
‫So let's go into here,
‫and we look at the log groups,
‫and we look at this one,
‫here we go that's my latest invocation.
‫As we can see the function was invoked
‫and the requests was successful.
‫But we don't know this,
‫if it was successful or not,
‫thanks to this command,
‫because this was an asynchronous invocation.
‫And we can do it for sure
‫because if we go into our Lambda function
‫and we're going to change the code to make it fail.
‫So I will comment the return
‫and I will uncomment the raise exception.
‫I'll deploy to save my changes.
‫Now if we test this function,
‫we know it fails.
‫It's just failed right now.
‫But if we use CloudShell again,
‫our CLI to invoke the function,
‫we get again a 202 status code for the error.
‫And I can know for sure that it has failed
‫because if I go into my log stream
‫and open this log stream,
‫we get an error right here.
‫So as we can see invoking the function asynchronously
‫returns the same status code 202
‫regardless of whether or not
‫the function succeeded or failed
‫because we don't want to know the results,
‫due to the nature of asynchronous.
‫So what we can do instead
‫is maybe set up a dead letter queue.
‫So if we go into our lambda function
‫and go to configurations,
‫under asynchronous invocations we have some information
‫and we can edit some configuration
‫around a dead letter queue.
‫So we have 0, 1 or 2 retry attempts
‫on the failure of an asynchronous event.
‫So we'll keep it as 2.
‫And then we can send the unprocessed events
‫from an asynchronous invocation
‫into a dead-letter queue.
‫So we can choose SQS
‫and we need to create an SQS queue for this.
‫So let's go into the SQS service,
‫and I'm going to create a queue,
‫and its going to be a standard queue called lambda-DLQ.
‫And I will click on create queue.
‫Now my lambda-GLQ has been created.
‫So let's go back into here and refresh this.
‫And now I need to refresh this page probably.
‫So let's refresh it,
‫edit the letter queue service SQS
‫and queue lambda-GLQ.
‫Here we go, it's appearing.
‫Save. And as we can see we can't save it
‫because the function does not
‫have enough permissions to call send message on SQS.
‫And so to fix that
‫we need to fix the IM role of our lambda function.
‫So if you go into our lambda function,
‫we go into our configuration
‫and general configuration permissions, sorry,
‫here is the execution role.
‫So we click on it,
‫so we're taking into the IM console,
‫and I'm going to attach a policy to it.
‫I will look for the SQS type of policy
‫and I will just give it,
‫the AmazonSQSFullAccess is going to be easy, at least.
‫And this way we are sure
‫that our lambda function can write into our SQS queue.
‫So back into our lambda console,
‫under the configuration for asynchronous,
‫we scroll down,
‫we save and this time,
‫yes it completes
‫and now my lambda function can write into SQS.
‫So, if we try to go now into our CloudShell,
‫and invoke this function again,
‫we'll know that the invocation itself will fail
‫because the lambda function function was coded to fail.
‫But now what's going to happen is that
‫the DLQ is going to kick into effect,
‫so we're gonna have 2 retry attempts,
‫and after the retry attempts have failed
‫then the message should go into Amazon SQS.
‫So right now if you're going to Amazon QS,
‫and we're going to send and receive messages
‫and look at the messages available.
‫We can pull from messages.
‫We have one message available.
‫This was just a test for the lambda function,
‫just to test whether or not
‫it was able to send some data into SQS.
‫So what I can do is that I can just
‫delete that message right here.
‫And now I'm going to wait 4 minutes
‫to see if my lambda function
‫sends a message to SQS due to the retries.
‫So let me pause the video and get back to you.
‫Okay, so now if I go into my CloudWatch logs,
‫and look at this log stream,
‫we can see something interesting.
‫So there is a request ID that surfaces 2ab,
‫and it's failed.
‫Then if we scroll down,
‫there is another request with 2ab,
‫so the same request ID,
‫and then it failed.
‫So that was the first retry.
‫And then there's another request with 2ab,
‫then it failed and that was the secondary retry.
‫So then the message went into the DLQ.
‫And so if we go into SQS and pull for messages,
‫we can see this message right here has failed.
‫And we can look at the key and the value,
‫and this was all the information around the message.
‫And if we look at the attributes of the message itself,
‫we can see that the error cause is 200,
‫something went wrong
‫and the request ID has 2ab in it,
‫so this corresponds to the invocation ID in lambda
‫that we can get directly from the message attributes in SQS.
‫So this really shows
‫that the asynchronous invocation and the DLQ work as well.
‫So this is for this hands-on.
‫I hope you liked it,
‫and I will see you in the next lecture.