great, so if I chose async not callback, then I don't need to set callbackWaitsForEmptyEventLoop,right? I found that if I use callback and callbackWaitsForEmptyEventLoop to be false, if there are still work after callback, if may not trigger this time, it will trigger the next time the lambda been triggered, very weird, async won't have this problem, right?
Nice video on async and callback functions difference in lambda and the contex.callbackWaitsForEemptyEventLoop feature. Please Explain what happens if the long-running task throws an error, how to catch it?. Thank you, have a good day and good health.
If you need to know the result of the task then you're going to have to await it (or use promise.then) if you're using async lambdas, or use callbacks to handle the result of the task. The method shown in this video is for fire and forget tasks. This does mean that your lambda will last for at least as long as the long running task.
Hey Sakar. Unfortunately Lambda doesn't throw an actual timeout error when the time runs out, it simply terminates the function which will cause API gateway to return a 500 series error with a vague message. I personally use exponential backoff on my front end to "keep trying" certain tasks that might timeout, and I detect if its a timeout by writing good error handling into my lambda functions. If I get a 500 series status code its a safe bet that its a timeout issue because I would not issue a 500 in any of my own error handlers.
@@CompleteCoding "The method shown in this video is for fire and forget tasks" what do you mean by "forget"? Does it leak to next execution of lambda or does it finish its sync task in the current execution after return 200?
Is there any advantage to doing the third call over the first? I traditionally would only use a callback if I needed to wait for something like in your second example?
In my opinion there is a massive disadvantage to using the third - not being able to use "await" in your code. This option was for those who are inheriting a legacy code base and are getting those timeout issues.
Few questions - do you need to 'return' the callback? I can see you that on some lines you do and some you don't. Also, are those _200() and _400() methods custom or part of node/aws sdk?
I don't think you need to return the callback. Honestly I've not worked with callbacks in about 3 years so I might not be doing it with best practices. The _200 and _400 are custom function. They just wrap the headers and other things to make it all cleaner const _200 = (data = {}) => { return { headers: { 'Content-Type': 'application/json', 'Access-Control-Allow-Methods': '*', 'Access-Control-Allow-Origin': '*', }, statusCode: 200, body: JSON.stringify(data), }; }
@@CompleteCoding I did some investigation and yes, you need.to return them, or use the context setting, but that can cause potential issues with subsequent calls on the lambda function. I like your idea of the custom functions for returning the different status codes, so might do the same as well as create a custom errors class
Hi Sam, I am facing this issue. I have tried using knex/sequelize to query mysql. I am using async/await syntax. my query is getting resolved. I have to emit an event to sns. However when I use second await example await sns.publish(params).promise(). nothing happens. In cloud watch I can see console statement above sns call. Not sure what is wrong? I am getting time out error 502. If I remove the sql async code then await sns works. I even tried commenting sql code and added normal axios api call and the sns. api call did not happen. Code you please guide. lambda timeout set to 1min
Hi Sam,
Does this also resolves the the timeout issue faced by the lambda?
For example if a request takes more than 30 seconds its getting timed.
This is a very important subject. Could expand more.
You videos are awesome and i am keenly following your channel .Thanks a ton
Thanks Sarir
Super interesting video and really useful. Thank you very much for all your super good content!
Glad it was helpful!
great, so if I chose async not callback, then I don't need to set callbackWaitsForEmptyEventLoop,right? I found that if I use callback and callbackWaitsForEmptyEventLoop to be false, if there are still work after callback, if may not trigger this time, it will trigger the next time the lambda been triggered, very weird, async won't have this problem, right?
Yes, I've not written a callback based lambda in years and haven't had to worry about callbackWaitsForEmptyEventLoop.
Nice video on async and callback functions difference in lambda and the contex.callbackWaitsForEemptyEventLoop
feature. Please Explain what happens if the long-running task throws an error, how to catch it?. Thank you, have a good
day and good health.
If you need to know the result of the task then you're going to have to await it (or use promise.then) if you're using async lambdas, or use callbacks to handle the result of the task. The method shown in this video is for fire and forget tasks.
This does mean that your lambda will last for at least as long as the long running task.
Hey Sakar. Unfortunately Lambda doesn't throw an actual timeout error when the time runs out, it simply terminates the function which will cause API gateway to return a 500 series error with a vague message.
I personally use exponential backoff on my front end to "keep trying" certain tasks that might timeout, and I detect if its a timeout by writing good error handling into my lambda functions. If I get a 500 series status code its a safe bet that its a timeout issue because I would not issue a 500 in any of my own error handlers.
@@CompleteCoding "The method shown in this video is for fire and forget tasks" what do you mean by "forget"? Does it leak to next execution of lambda or does it finish its sync task in the current execution after return 200?
Is there any advantage to doing the third call over the first? I traditionally would only use a callback if I needed to wait for something like in your second example?
In my opinion there is a massive disadvantage to using the third - not being able to use "await" in your code. This option was for those who are inheriting a legacy code base and are getting those timeout issues.
Why youtube doesn't provide 3 time speed?
People have said that they watch some videos at 1.5-2x but I've never heard of people wanting it even faster
Few questions - do you need to 'return' the callback? I can see you that on some lines you do and some you don't.
Also, are those _200() and _400() methods custom or part of node/aws sdk?
I don't think you need to return the callback. Honestly I've not worked with callbacks in about 3 years so I might not be doing it with best practices.
The _200 and _400 are custom function. They just wrap the headers and other things to make it all cleaner
const _200 = (data = {}) => {
return {
headers: {
'Content-Type': 'application/json',
'Access-Control-Allow-Methods': '*',
'Access-Control-Allow-Origin': '*',
},
statusCode: 200,
body: JSON.stringify(data),
};
}
@@CompleteCoding I did some investigation and yes, you need.to return them, or use the context setting, but that can cause potential issues with subsequent calls on the lambda function.
I like your idea of the custom functions for returning the different status codes, so might do the same as well as create a custom errors class
can we use return callback() in aws lambda?
You can but I would avoid it if you can. Use async/await and it will make your life so much easier.
Hi Sam, I am facing this issue. I have tried using knex/sequelize to query mysql. I am using async/await syntax. my query is getting resolved. I have to emit an event to sns. However when I use second await example await sns.publish(params).promise(). nothing happens. In cloud watch I can see console statement above sns call. Not sure what is wrong? I am getting time out error 502. If I remove the sql async code then await sns works. I even tried commenting sql code and added normal axios api call and the sns. api call did not happen. Code you please guide. lambda timeout set to 1min
Could you share a link to the code?
@@CompleteCoding thanks Sam, it’s fixed now. It was a Vpc issue
@@the-gr8-eye glad you got that fixed
love your content man
Thanks, that means a lot
Good explanation!
Glad it was helpful!
Thx!
No problem!