Concat stderr and stdout before parsing incoming events, including la…

[icarus-sullivan]

…test mock-lambda

Description

Merge stderr and stdout in the response parsing from go invocation

Motivation and Context

There was a check for stderr to return early during the lambda invocation. This was to improve performance as it would ignore stdout. Apparently standard log outputs will write to the stderr channel in golang, so instead we should merge all output and parse it. Any extra lines not marked with the identifier offline_payload will be output to the console. Also adding and pinning a change to the mock-lambda which runs the code to support SQS events as well as uses reflection to infer incoming events.

Why is this change required? What problem does it solve? Issue 1352

How Has This Been Tested?

Added an additional log call in the test go runner to verify these changes fix 1352 and don't break existing functionality.

[icarus-sullivan]

For visibility, this is the commit hash for the mock-lambda changes icarus-sullivan/mock-lambda@b33d704

[icarus-sullivan]

Not needed by the new mock-lambda version

[walterdl]

Hello @icarus-sullivan,

Trying to be an early adopter of this change I experienced the same problem. I tried getting your changes in two ways:

1. Running your fork in the branch go/log-patch by installing the root npm dependencies and running go mod download in test/instegration/go/go1.x. Doing sls offline and hitting the lambda /dev/hello I get a 502 status code. Trying deleting the log.Println that you left there I get the desired HTTP response.
2. Installing serverless-offline with your changes using npm i https://github.com/icarus-sullivan/serverless-offline#go/log-patch and having the mock-lambda module with version v0.0.0-20220217054640-b33d704534c9. It still gave me a 502 status code.

Neither log.* nor fmt.* log methods work.

Please, tell me whether I got your changes in the wrong way. Maybe it could be a problem on my side.

Thanks :)

[icarus-sullivan]

@walterdl Can you send me a sample repo with what you have? It might sound silly, but you may or may not have to run npm run build in the serverless-offline#go/log-patch install. I don't know if that is automatic with installs from github.

For maximum clarity the steps I use are:

my changes

• Clone repo
• Install node dependencies
• npm run build
• yarn link (or npm link) - This allows you to use our local version while installing serverless-offline

mock-lambda

• Should be installed automatically with the latest changes by the GoRunner

Code example

• Create simple serverless project
• Run yarn link "serverless-offline" - (Links our local changes to this project instead)
• Set up a simple go http endpoint
• Run serverless-offline
• Ping test endpoint locally

[walterdl]

Hi @icarus-sullivan, I followed your suggested steps and the problem persisted 🙈. I tough it was going to work because I missed the npm run build step in the local serverless-offline#go/log-patch installation. However, despite having the sls-offline built and linked in my testing project I still received the 502 due to the log.Print. The below image proves that I had the linked version of sls-offline already built with your latest changes.

Anyways, here is the sample repo that I used to test the changes: https://github.com/walterdl/golang-windows-sls-offline-log-bug. Its package.json doesn't have any dependency since I used the linked sls-offline package.

[icarus-sullivan]

@walterdl Can you clone my sample repo here https://github.com/icarus-sullivan/go-log-patch-sample

All you should have to do is:

yarn install 
yarn dev

Then you can hit the url:

curl --location --request GET 'http://localhost:3000/dev/hello'

[walterdl]

@icarus-sullivan I tested with your sample repo but I got the same situation. None difference. I even tested it in a fresh installation of Golang in a different windows machine. However, it worked without problems in macOS. Did you really test this on a Windows machine? It's so weird that you say it works but on my side don't.

[icarus-sullivan]

@walterdl No I didn't test on a windows machine, I haven't owned one for over a decade. If you can help debug in any way that would be great. Let me know if you think it is related to paths not resolving correctly, that would be my only suspicion but I'm far from a windows expert.