Different behavior of context.succeed() vs callback() in AWS Lambda

lambda.js

//
// Lambda's timeout needs to be >5 seconds, 10 should do
//

var startedAt = new Date();

var interval = setInterval(function () {
    console.log(startedAt, new Date());
}, 1000);

exports.handler = function (event, context, callback) {
    setTimeout(function () {
        console.log('returning');
        // v1:
        return callback(null);
        // v2:
        // return context.succeed();
    }, 5000);
};

Thanks a lot, very helpful.

Even with callbackWaitsForEmptyEventLoop set to false so that callback() doesn't timeout the function, I can't figure out a reason specifically to use callback(null, result)/(err) over context.succeed()/fail(). The syntax is less clear AND you have to change settings for it to work properly (and apparently doing so may cause unexpected behavior on the next invocation - unacceptable in a production environment).

Am I missing something? Is there a real reason for me to change all my context.succeed()/fail() calls to callback()? Fear of deprecation is the only thing that comes to mind.

@slaughtr imho, callbacks are a more natural way of doing it in Node.js since many frameworks/libraries already manage callbacks natively. It allows you to write more general/reusable code in your functions. On the other hand, using context means that every piece of your code must be aware of its existence. And well, the same holds for your unit tests.

In other words, there is "no technical advantage" besides coding style, conventions, reusability, and maintainability.

The nodejs event loop in your case may not be empty that's why the callback function doesn't work and when you set callbackWaitsForEmptyEventLoop= false, the event loop is not into consideration and the function is terminated straight away.

This may be happening because of the open connections to databases or waiting on some other I/O operation which is not letting the event loop to go empty.

@DaVincii is right, I can use callback() and it completes the request as long as there's no other connection/process hanging, in my case the connection to the db was still open so my lambda would timeout and never complete the request, after closing the client connection it resolved as expected.

same as @rodrigomf24, I forgot my db connection open.. after closing it resolved as expected.