Bug: validation module should return 400 on error

[scottgerring]

When you use the @Validation annotation on a RequestHandler and the provided message does not validate, the module will throw a ValidationException, resulting in a 500 back to the client.

Changing this behaviour is a breaking change.

What were you trying to accomplish?
I would expect that validation errors should return a 400 and a description of why the validation failed. Alternatively if the annotation is applied to something other than a RequestHandler, throwing an exception for the user's code to catch seems reasonable.

Current Behavior

ValidationException / HTTP 500 returned to user.

Possible Solution

Steps to Reproduce (for bugs)

Check out the validation example as it exhibits this behaviour.

[jeromevdl]

Not that simple as we perform some validation on many different events, not only API GW...

400 is only applicable to API GW events and responses (APIGatewayProxyRequestEvent, APIGatewayV2HTTPEvent, APIGatewayProxyResponseEvent and APIGatewayV2HTTPResponse), otherwise an exception is still valid.

[scottgerring]

Good point. Should we add some return-type specific behavior?

The alternative seems to be saying we aren't supporting the annotation directly on the handlers function itself, but only on "other methods"; then in the case of a HTTP API integration, the user's handler wraps this "other method", catches the exception, and maps back to a 400.

I feel that validation on a HTTP API is "common path" and should work without this level of glue. What do you reckon?

[jeromevdl]

Either we document how to not use the annotation and use the ValidationUtils in case of API and catch the validation exception to return 400. This is what python did (doc)

Either we implement this in the library : in case of one of the events above, we change the http code in the response to 400 and update the body with an error message... Probably a better experience for users but will be opinionated (message format: json? plain txt?).

[scottgerring]

Let's tie this into the broader module-review issue for V2 - #1469. Oner person can knock both of these off at once.

[skal111]

Happy to take that one