Serverless-offline: Support lambda invoke for lambdas that do not conform to API Gateway response standard

[brocksamson]

I have a simple lambda (python 3.6) that returns a json bundle. This lambda doesn't live behind an API gateway. Instead it's invoked directly by other lambdas & EC2 instances within our system. #698 did almost all the work needed for this library to be an arbitrary lambda runner on your local system.

However, within the functionHelper.runProxyHandler function the regex is enforcing both that the json response be an object and also that the first property inside the json bundle is one of the following: isBase64Encoded, statusCode, headers, body, or principalId. Since this lambda isn't invoked via API Gateway there isn't any reason for us to follow the API Gateway response standard.

Is being able to invoke arbitrary lambdas directly something that you're willing to support in this library? Based on some quick hacking within runProxyHandler the code here works correctly for my scenario, the regex is simply failing to detect the json bundle start.

If you're willing to include this scenario within this library, then I'd be happy to make the necessary code changes.

[alur222]

hi @brocksamson were you able to find a workaround for this? My problem is also similar in a way that I am invoking another lambda from a cron lambda (scheduled).

Also, just to confirm. The current version only works if you invoke another lambda from a api-gateway triggered lambda:

postman --> lambda1 --> lambda2

and doesn't work when you do this:

cron lambda --> lambda2

[alur222]

My current work-around is still build a cron/scheduled lambda and trigger the other lambda via api-gateway endpoint. :clinking_glasses:

[brocksamson]

Unfortunately, there isn't really a none hack way to get around this right now. The base problem is that the regex being run on the response won't match up unless the first element matches an element of the API Gateway standard.
I've got a fork that is working for my scenario, but its not quite ready for prime time. Hopefully I'll have it done today or tomorrow.
The only other options that works at this time is to conform your lambda response to the API gateway json structure & then put your actual structure under the body element.

[alur222]

Thank you for the insights. As I am very new to these things, can you tell me if it's a bad practice to call another lambda via api-gateway considering that it's gonna be inside a loop?

[brocksamson]

@alur222 Its not really bad practice, but its definitely less efficient than simply calling the lambda directly. Also it means you've exposed your lambda to malicious scripts on the internet, which means you should be really certain you've properly secured it.
I've committed my changes to my fork. I'm still testing them to be sure they're sufficient for my needs, but feel free to try them out and see if it improves things on your side.

[dnalborczyk]

hey @brocksamson could you create a small repro repository which outlines your problem?

[brocksamson]

Check out the changes to src/__tests__/manual/python/handler.py within #752. That handler fails if you set raw_response=true in the qs when calling it. You can get the curl command for this within the README.md in that same directory from my PR.

I just realized that PR has conflicts, will update.

[brocksamson]

I finally tested my 2 scenarios and this issue is resolved in your latest alpha tag. Thanks for looking into this! :+1: