-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Invalid API Gateway Response Keys: {'base64Encoded'} in {'statusCode': 200, 'headers': {'Content-Type': 'text/plain'}, 'body': 'Hello World', 'base64Encoded': False} #1193
Comments
@psaws This is a duplicate of #830. See my comment here: #1190 (comment) Closing as duplicate. |
I miss read the issue, my fault. |
@psaws SAM CLI does not serialize the data. The expected key is "isBase64Encoded" from https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-output-format. You should cut an issue against the aws-serverless-java-container-core project. |
It seems like this issue was fixed on aws-serverless-java-container-core side in 1.3.2, but I am still getting the same error. |
Would be great to see this fixed for those working with custom event types. |
I am still experiencing this issue locally using the 1.3.2 version. |
Hello, here are my notes on how I could get it working by duplicating your class and playing around with annotations. Failed attempts
Successful attempts
Still trying some others that are backwards compatible, but please address this in some way. |
I am still getting the issue. I am trying to follow this tutorial: https://aws.amazon.com/blogs/opensource/java-apis-aws-lambda/
It is Jan 2020, should this not be fixed by now? |
This is not related to SAM CLI and is a combination of AWS Lambda and they dependency you use: aws/serverless-java-container#262 (comment) SAM CLI only serialize the output of the container into json, therefore if you are running into this issue, something is wrong in your serialization within your code. Closing as it is not something SAM CLI controls. @afayes You are getting that error because the keys are wrong in your output ( |
For Kotlin: Use @JvmName |
Here's an example trace running local (1.3.2)
Please notice the application is returning a correct proxy object (the json you see is from me serializing the {"statusCode":200,"multiValueHeaders":{"Content-Type":["application/json"]},"body":"{\"name\":\"foo\",\"isbn\":\"f3634054-18be-4493-874a-ce0693724031\"}","isBase64Encoded":false} But gateway is seeing something else {'statusCode': 200, 'multiValueHeaders': {'Content-Type': ['application/json']}, 'body': '{"name":"foo","isbn":"f3634054-18be-4493-874a-ce0693724031"}', 'base64Encoded': False} This leads to an HTTP response of BAD GATEWAY.
Now this exact same code is deployed to api-gateway, and the response is correct
Cloud watch logs don't show what lambda sends to gateway, but here's the comparable log output that goes with the above sam local log.
|
Looking at the object returned by the serverless java container ( @JsonProperty("isBase64Encoded")
public boolean isBase64Encoded() {
return isBase64Encoded;
}
public void setBase64Encoded(boolean base64Encoded) {
isBase64Encoded = base64Encoded;
} So I think upstream is not responsible for this. In my comments above I serialized this object with Jackson, and as you can see, the serialization also results in In your comment above where you say "SAM CLI only serialize the output of the container into json", I believe you are saying that CLI serializes the There is a ticket on this problem over at serverless java container... aws/serverless-java-container#262 |
Description
We are using aws-serverless-java-container-core to set up our API Gateway proxy lambdas. Each lambda returns an AwsProxyResponse. When run in AWS these lambdas work fine through the configured API Gateways; however, when testing locally with the aws-sam-cli (sam local start-api) we are only able to receive 502 Bad Gateway responses from the local gateway.
It appears that release 0.16.0 of aws-sam-cli added validation to the parameters returned from lambdas (#1154). When we check the logs for our local lambdas we find that the property for base64encoding is not respecting the declared JsonProperty annotation and is being serialized with a value different that the one that is expected. The serialized value is consistent between the local and AWS environments.
This is a similar issue to the one described in issue 830, but it is unrelated. We are not using the multiValueHeaders field in any of our lambda responses, and the attached error log does not contain this field.
The issue we are facing is that the "isBase64Encoded" field of the AwsProxyResponse object is being serialized with a name of "base64Encoded" rather than the expected name of "isBase64Encoded". This is resulting in all requests to the local gateway returning 502 regardless of the actual status of the lambda. We are using the AwsProxyResponse object provided by aws-serverless-java-container-core defined here: https://github.com/awslabs/aws-serverless-java-container/blob/master/aws-serverless-java-container-core/src/main/java/com/amazonaws/serverless/proxy/model/AwsProxyResponse.java
Downgrading the aws-sam-cli to version 0.15.0 does prevent the issue from occurring as there is no validation logic present in that version
Additional environment details (Ex: Windows, Mac, Amazon Linux etc)
aws-sam-cli version: 0.16.1
aws-serverless-java-container-core version: 1.3
Add --debug flag to command you are running
Error Log:
2019-05-22 14:56:37 Invalid API Gateway Response Keys: {'base64Encoded'} in {'statusCode': 200, 'headers': {'Content-Type': 'text/plain'}, 'body': 'Hello World', 'base64Encoded': False}
2019-05-22 14:56:37 Function returned an invalid response (must include one of: body, headers or statusCode in the response object). Response received: {"statusCode":200,"headers":{"Content-Type":"text/plain"},"body":"Hello World","base64Encoded":false}
2019-05-22 14:56:37 127.0.0.1 - - [22/May/2019 14:56:37] "GET /echoStatusCode/200 HTTP/1.1" 502 -
The text was updated successfully, but these errors were encountered: