10
votes

I have an AWS API Gateway setup, served by a Python Lambda function. For successful responses the Lambda returns a response of the form:

"200:{\"somekey\": \"somevalue\"}"

By default, the Integration Response settings in the gateway console have just one rule configured with a Lambda Error Regex of .* mapping to a response status of 200. This works fine.

The problem is when I try to change that to 200.* (with a view to enabling more specific codes going forward). Now I get a

{"message": "Internal server error"}

every time I hit the gateway with any request (resulting in a 200 or not).

No error logs are written to CloudWatch.

enter image description here

I want to know how I can map Lambda outputs to HTTP status codes successfully in AWS API Gateway.

2
You did look at this, yes? stackoverflow.com/questions/31329495/…Nefariis
My issue was a type in my 200 response regex.mewc

2 Answers

15
votes

If you do a test run in API gateway, the test run log should show an error similar to:

Sat Nov 21 07:41:25 UTC 2015 : Execution failed due to configuration error: No match for output mapping and no default output mapping configured

The problem is there is no-longer a default mapping to catch a successful response. The intention of the error regex is to catch errors and map them to status codes. The error regex searches the errorMessage property of the failed json response. If you were to set the status code 400 to be the default (blank) - you would find your successful response always mapping to a status code of 400.

You'll be best off to leave 200 as a default (blank) regex. Then set specific regex values to check for your different error messages. For example, you can have multiple specific error regex status codes and a generic catch-all to result in 500's.

enter image description here

2
votes

For those who tried everything put on this question and couldn't make this work (like me), check the thedevkit comment on this post (saved my day):

https://forums.aws.amazon.com/thread.jspa?threadID=192918

Reproducing it entirely below:

I've had issues with this myself, and I believe that the newline characters are the culprit.

foo.* will match occurrences of "foo" followed by any characters EXCEPT newline. Typically this is solved by adding the '/s' flag, i.e. "foo.*/s", but the Lambda error regex doesn't seem to respect this.

As an alternative you can use something like: foo(.|\n)*