-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Long execution time caused by callbackWaitsForEmptyEventLoop=true
on AWS Stream
#264
Comments
You can call this function and you will have access to the serverless-adapter/src/core/current-invoke.ts Lines 28 to 42 in 53d431b
Are you using |
🤔 Where would I call this function? Our entire handler creation looks like this: export const handler = ServerlessAdapter.new(app)
.setFramework(new ExpressFramework())
.setHandler(new CustomAwsStreamHandler())
.setResolver(new DummyResolver())
.addAdapter(new ApiGatewayV2Adapter())
.build(); This is following the documentation, which states that only |
Oh, I got it, I didn't see you were using AWS Stream Handler. Hm... in this case, I think is worthy to have a flag to control this behavior, I'm suspect you have something in your event loop that makes the lambda keep alive for that amount of time but since resolving the promise is not enough, having that flag always Thanks for reporting this, I will probably add a option to customize that value in the future, and in a breaking change, I will try to make it default to |
callbackWaitsForEmptyEventLoop=true
on AWS Stream
That is wonderful, thank you! Yes, we clearly have some DB connections or something that aren't getting closed. We always used this setting with the non-streaming API, so we just needed a way to continue using it. |
feat(aws-stream-handler): add flag to customize callbackWaitsForEmptyEventLoop (#264)
Just to let you know, I released a new version with the |
Wow, thank you very much! |
Feature Request
We needed to set
callbackWaitsForEmptyEventLoop
tofalse
for our use-case; without this, our lambda invocations were taking 30s instead of 8ms, so it's a huge deal for us.It was a bit difficult to figure out how to access and modify the AWS context object, so I wanted to share our solution here for others to use in the future:
The text was updated successfully, but these errors were encountered: