Serverless-offline: Invoke: InvocationType Event not behaving asynchronously like AWS Lambda

[andreme]

When invoking a function with the InvocationType Event, in AWS Lambda the promise is resolved as soon as the request is sent. serverless-offline waits until the function has finished running.

        response = await lambda.invoke({
            FunctionName: 'z',
            Payload: '{}',
            InvocationType: 'Event',
        }).promise();

Can that be fixed?
I can probably create a PR if you point me in the right direction.

[dnalborczyk]

hey @andreme yes, that can probably be fixed. which version of the plugin are you using? the code base has diverged quite a bit from v5 to v6 - and only v6 is under active development. new features should go into master.

[dnalborczyk]

I can probably create a PR if you point me in the right direction.

I'm guessing the event type is probably in the header.

to fix this you probably have to look into: https://github.com/dherault/serverless-offline/tree/master/src/events/http/http-routes/invoke

tests are located here: https://github.com/dherault/serverless-offline/tree/master/tests/integration/lambda-invoke

[andreme]

@dnalborczyk Thanks, I'm using 6, but it's not a real problem for me, just noticed it. I'll have a look and see if I can fix it in 6

[dnalborczyk]

@dnalborczyk Thanks, I'm using 6, but it's not a real problem for me, just noticed it. I'll have a look and see if I can fix it in 6

awesome. sounds good! btw, I hastily added some contribution guidelines: https://github.com/dherault/serverless-offline/blob/master/CONTRIBUTING.md let me know if something is not clear and can be improved.

[dnalborczyk]

out of curiosity, do you use InvocationType: 'Event' when you are not interested in the response? or one might possibly get the result later by another event or maybe by polling?

[andreme]

The lambda generates a file and stores it in S3 (because it's too big to be transferred through the API gateway), and the client directly downloads it from there.

[dnalborczyk]

@andreme

implemented preliminary support in: https://github.com/dherault/serverless-offline/commit/fcae27fe2224e5e54b2217bba929720a862842a4 let me know if it works as expected.

I'll update this issue when it's published.

_update, published:_ https://github.com/dherault/serverless-offline/releases/tag/v6.0.0-alpha.49

[andreme]

@dnalborczyk Thanks for that. I was not able to get 6 (1.58.0/6.0.0-alpha.49) running.
Likely unrelated to this commit, but I've attached the debug output for both versions.
Looks like it has a problem detecting the routes. My setup is a bit unusual I guess because I use serverless only to run lambda locally.

start5.txt
start6.txt
serverless.yml.txt

[dnalborczyk]

I was not able to get 6 (1.58.0/6.0.0-alpha.49) running.

was it running before with a previous alpha version? since you mentioned above you are using 6.x already.

thanks for the files. I have to check what happens if one only runs the lambdas without any endpoints. re-opening this issue as a reminder.

[andreme]

@dnalborczyk sorry, that was supposed to read 'I'm using 5'
So no I don't know if it was running with a previous alpha.
If you have a guess which version might have introduced this problem I can test that.

[dnalborczyk]

@andreme just checked. there seems to be a bug if you only create lambdas without an endpoint. you could create a temporary end point as a placeholder until this is fixed.

[dnalborczyk]

@andreme

alpha 50 (https://github.com/dherault/serverless-offline/releases/tag/v6.0.0-alpha.50) should fix your issue. keep in mind that the lambda (invoke) http port is now 3002 by default. you can change it in the options though with lambdaPort.

let me know if it works.

[hntrl]

Is there the possibility of an option where the lambda endpoint isn't exposed?

[andreme]

@dnalborczyk Thank you. I can confirm it works now as expected.

[dnalborczyk]

Is there the possibility of an option where the lambda endpoint isn't exposed?

there is no option yet, although it could be added. not really sure if it would be beneficial, other than a resource and performance improvement and using one less port.

do you have a specific use case @hntrl ?

[hntrl]

That's exactly it @dnalborczyk.
I'm using multiple serverless-offline instances to simulate a whole suite of services, then proxying them together. Ideally, I'd want to reduce the footprint of the ports consumed, which this option would do.
That, or monorepo support in some way. Either one would fit my use case.