Invoke local successfully but time out on AWS

Serverless Framework
1

I’m using bluebird Promise in my handler method. The function returns successfully when I invoke on local but time out when running on Lambda. The callback methods on local and lambda seem to be different too.

I can see the result of my method on lambda log. However when I call callback(null, response) nothing seems to happened. It just stuck there and time out.

What can I do about it?

2

Are you setting a specific timeout value? Do you have logging to see what it’s (stuck?) doing when it times-out? Without knowing what kind of work your function is doing and what timeout value you’ve set, there’s no way for us to know if you’re not getting a legitimate timeout in Lambda…

What do you mean by:

exactly? What calls? How are they different?

The only other thing I can think of is to check when/if you’re returning your callback() calls, as that sometimes can result in different end-states in the Lambda environment vs locally.

3

No I didn’t set specific timeout value from code.
My function queries my db and returns result. I can see the result from my query already, but it stuck at this line

return callback(null, response)

The callback functions in the signature. When I invoke locally, the body of that method is the body of callback you can find in invokeLocalNodeJs(handlerPath, handlerName, event) in lib/plugins/aws/invokeLocal/index.js, while body of that method when running on Lambda is

    (err, data) => {
        if (consumed) {
            return;
        }
        consumed = true;
        finish(err, data, waitToFinish);
    }

I did `return callback(null, response)``` from the promise.

On a side note, when I invoke locally, after I see my result, it takes about 40s until it completely stop.
After raising the timeout to 40s, I can get successful result from Lambda and got charged for 30s. My query is very fast, should complete under 1s. Is there something I need to pay attention to here?

4

The default timeout for a Lambda is 3 seconds so that’s why it was timing out earlier. It sounds like something funny is going on and I would investigate why it’s taking so long.

In your original message you mentioned using Bluebird Promises. Can I ask why? Node already has support for Promises.

5

Cool, I didn’t know about the differences in the payload.

+1 to @buggy’s suggestion to use native Promises; That’s what I use, and haven’t had any issue.

Do you have any logging or instrumentation that tells you where the function is spending all of its time in Lambda? i.e. if the query should be finished in <1 second, can you see if that is happening when run in Lambda?

6

If your event loop isn’t empty lambda will hold back the handler callback by default. (eg. you kept a connection open with your db)

Use this property to prevent it from responding.

context.callbackWaitsForEmptyEventLoop = false;

I think “sls invoke local” should replicate this behavior to avoid confusion (will create an issue).

1 Like
7

With Mongoose in my NodeJS handler, I had to manually mongoose.disconnect() just before my callback() call. This was the only thing that prevented the timeouts.