ajschmidt8
commented
2 years ago Actually, I have some additional thoughts/questions on this. @gr2m, can we remove the try/catch block in this file? Here's my reasoning:
According to the docs linked in my original post:
API Gateway treats all invocation and function errors as internal errors. If the Lambda API rejects the invocation request, API Gateway returns a 500 error code. If the function runs but returns an error, or returns a response in the wrong format, API Gateway returns a 502. In both cases, the body of the response from API Gateway is {"message": "Internal server error"}.
When the serverless.yaml file has a value of async: false (the default value), the try/catch works fine because API Gateway waits for either the 200 or 500 response that is returned by the Lambda function and returns that to the client.
However, when a value of async: true is used, where API Gateway does not wait for a response from and instead returns a 200 response to the client immediately, the try/catch block makes it hard to track down errors (as in #78) since the Lambda function does not currently throw any errors. So in this case, we have both an API Gateway response returning a 200 and also the Lambda function not throwing any errors despite errors having actually occurred.
The impact of removing the try/catch block would be this:
When async: false (the default), if an error occurs, the Lambda will correctly throw an error, and API Gateway will return a 502 response with a JSON response of {"message": "Internal server error"}.
When async: true, if an error occurs, the Lambda will correctly throw an error, but API Gateway will still continue to return a 200 response as expected.
Hopefully that all makes sense. I can elaborate more if necessary.
gr2m
Using a
try/catchblock prevents Lambda function errors from being properly interpreted by AWS.Removing this block will maintain the existing functionality, but allow Probot errors to be properly propagated to AWS Lambda.