I have a simple lambda function that asynchronously makes an API calls and then returns data. 99% of the time this works great. When ever the API takes longer then the lambda co
I've run into the same issue, in fact there are many cases when Lambda becomes unresponsive, e.g.:
Parsing not valid json:
exports.handler = function(event, context, callback)
{
var nonValidJson = "Not even Json";
var jsonParse = JSON.parse(nonValidJson);
Accessing property of undefined variable:
exports.handler = function(event, context, callback)
{
var emptyObject = {};
var value = emptyObject.Item.Key;
Not closing mySql connection after accessing RDS leads to Lambda timeout and then it becomes non-responsive.
When I'm saying unresponsive it's literally not even loading, i.e. first print inside handler isn't printed, and Lambda just exits every run with timeout:
exports.handler = function(event, context, callback)
{
console.log("Hello there");
It's a bug, known by AWS team for almost a year:
https://forums.aws.amazon.com/thread.jspa?threadID=238434&tstart=0
Unfortunately it's still not fixed, after some tests it's revealed that in fact Lambda tries to restart (reload the container?), there is just not enough time. If you set the timeout to be 10s, after ~4s of execution time Lambda starts working, and then in next runs comes to behave normally. I've also tried playing with setting:
context.callbackWaitsForEmptyEventLoop = false;
and putting all 'require' blocks inside handler, nothing really worked. The only way to prevent Lambda becoming dead is setting bigger timeout, 10s should be more than enough as a workaround protection against this bug.