# Invoke local successfully but time out on AWS **URL:** \ **Category:** Serverless Framework\ **Tags:** aws\ **Created:** [December 30, 2016, 9:07am UTC](https://forum.serverless.com/t/invoke-local-successfully-but-time-out-on-aws/1027 "2016-12-30T09:07:02Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![hoangphuoc25](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/hoangphuoc25/32/4268_2.png) [@hoangphuoc25](https://forum.serverless.com/u/hoangphuoc25)\ **Post date:** [December 30, 2016, 9:07am UTC](https://forum.serverless.com/t/invoke-local-successfully-but-time-out-on-aws/1027/1 "2016-12-30T09:07:02Z")
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? ---
**Author:** ![rowanu](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/rowanu/32/75_2.png) [@rowanu](https://forum.serverless.com/u/rowanu)\ **Post date:** [December 30, 2016, 10:12am UTC](https://forum.serverless.com/t/invoke-local-successfully-but-time-out-on-aws/1027/2 "2016-12-30T10:12:09Z")
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: > [@hoangphuoc25](#): > > The callback methods on local and lambda seem to be different too. exactly? What calls? How are they different? The only other thing I can think of is to check when/if you’re `return`ing your `callback()` calls, as that sometimes can result in different end-states in the Lambda environment vs locally. ---
**Author:** ![hoangphuoc25](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/hoangphuoc25/32/4268_2.png) [@hoangphuoc25](https://forum.serverless.com/u/hoangphuoc25)\ **Post date:** [December 30, 2016, 11:00am UTC](https://forum.serverless.com/t/invoke-local-successfully-but-time-out-on-aws/1027/3 "2016-12-30T11:00:30Z")
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 ```auto return callback(null, response) ``` > [@rowanu](#): > > What calls? How are they different? 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 ```auto (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? ---
**Author:** ![buggy](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/buggy/32/177_2.png) [@buggy](https://forum.serverless.com/u/buggy)\ **Post date:** [December 30, 2016, 12:24pm UTC](https://forum.serverless.com/t/invoke-local-successfully-but-time-out-on-aws/1027/4 "2016-12-30T12:24:52Z")
> [@hoangphuoc25](#): > > 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? 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. ---
**Author:** ![rowanu](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/rowanu/32/75_2.png) [@rowanu](https://forum.serverless.com/u/rowanu)\ **Post date:** [December 31, 2016, 5:06am UTC](https://forum.serverless.com/t/invoke-local-successfully-but-time-out-on-aws/1027/5 "2016-12-31T05:06:32Z")
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? ---
**Author:** ![leeeomaaax](https://avatars.discourse-cdn.com/v4/letter/l/a9a28c/32.png) [@leeeomaaax](https://forum.serverless.com/u/leeeomaaax)\ **Post date:** [April 11, 2017, 7:11pm UTC](https://forum.serverless.com/t/invoke-local-successfully-but-time-out-on-aws/1027/6 "2017-04-11T19:11:35Z")
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). ---
**Author:** ![hotdang-ca](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/hotdang-ca/32/1396_2.png) [@hotdang-ca](https://forum.serverless.com/u/hotdang-ca)\ **Post date:** [December 11, 2017, 6:56pm UTC](https://forum.serverless.com/t/invoke-local-successfully-but-time-out-on-aws/1027/7 "2017-12-11T18:56:43Z")
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.