Invalid API Gateway Response Keys: set([u'multiValueHeaders']) in with `sam local start-api`

[AyushG3112]

Description

I am trying to test my local function with sam local start-api but it appears to make an useless validation to the response.

Observed result

Invalid API Gateway Response Keys: set([u'multiValueHeaders']) in {u'body': u'{"Status":true,"Message":"OTP Generated"}', u'headers': {u'Content-Type': u'application/json'}, u'multiValueHeaders': {}, u'statusCode': 200}

Function returned an invalid response (must include one of: body, headers or statusCode in the response object). Response received: {"statusCode":200,"headers":{"Content-Type":"application/json"},"multiValueHeaders":{},"body":"{\"Status\":true,\"Message\":\"OTP Generated\"}"}

Expected result

Describe what you expected.

Additional environment details (Ex: Windows, Mac, Amazon Linux etc)

1. OS: Ubuntu 16.04
2. sam --version: SAM CLI, version 0.16.0

[jfuss]

Duplicate of #830

Closing

[btipling]

@jfuss I think this may be a different issue from #830 because in this case it returns an error from the local API Gateway level. #830 didn't return an error I think.

[jfuss]

At the root of it, we need to support multiValueHeaders. So the ask here is the same as the other issue.

[btipling]

The issue though seems to be that something is preventing from even a basic hello world from succeeding in my codebase. All my lambdas are currently failing with 502 HTTP errors, something changed that introduced the multiValueHeaders or the new 502 errors without any code changes. I haven't created a reduced reproducible example yet, because I am not entirely sure that it isn't something wrong with my vendor or some version conflict. I did a quick search for this error and saw this and thought maybe someone else was running into this as well.

[btipling]

Reverting to 0.15.0 resolved my issue. It looks like there is a conflict with some of the golang aws packages that send the multivalue headers. They were ignored, but now they generate a 502 error breaking all endpoints for something being generated by an aws lib.

$ cd vendor/github.com/; ag -li multivalue
awslabs/aws-lambda-go-api-proxy/core/request.go
awslabs/aws-lambda-go-api-proxy/core/response.go
aws/aws-lambda-go/events/alb.go
aws/aws-lambda-go/events/apigw.go

When I manually removed the references in structs to multivalue in these files:

vendor/github.com/awslabs/aws-lambda-go-api-proxy/core/response.go
vendor/github.com/aws/aws-lambda-go/events/alb.go
vendor/github.com/aws/aws-lambda-go/events/apigw.go

The 502s stopped with this change, but instead of settling with this as a temporary fix, I just reverted to 0.15.0 and the problem went away. I think this is a separate issue worth investigating. The 502 is harsh given that other aws official libs are automatically sending that header. It wasn't fun to suddenly have everything break on me without any changes on my part. Having said that, I appreciate the value this tool brings and am grateful for all the work that has gone into it. Just providing some feedback about user experience.

[jfuss]

@btipling So there are multiple things at play here. We made some of our validation on returns (in the Api Gateway context) to match what the service does. When doing this, we did not add support for multiValueHeaders since start-api doesn't actually support this yet. So while we are now failing because of these 'unexpected' values it is actually an expected behavior until we support multiValueHeaders. This is why the two issues are the same even though the error is different (the other issue was just created before it started erroring out like this).

[AyushG3112]

@jfuss can we patch a fix in for now till the proper fix is merged and released?

[jfuss]

We have an open PR that is currently being iterated on. Downgrading the CLI will be the path forward until we merge the PR and release.

[havsar]

Reverting to 0.15.0 worked for me too.

0.15.0 release link: https://github.com/awslabs/aws-sam-cli/releases/tag/v0.15.0