How to handle improper input types?

[alteredtech]

Question

I am working on figuring out a contract test to ensure the server is responding with what we expect it to be sending back. I am experimenting with a tool called schemathesis. This tool creates random data to test against the server with and ensures the return matches what the spec says.
One thing it tests for is if you use Int64, it does one more to ensure you are handling those overflows correctly.

Well this is where I am getting the error with my lambda function. The generated server code doesnt allow me to handle improper input data that I am aware of. It errors before reaching my function for the endpoint.

Would this be where I create a middleware to implement this functionality?

[alteredtech]

I think this is being discussed here #609 Since it is the client that is sending incorrect data, not a server issue but just no way of handling that.

[czechboy0]

Well this is where I am getting the error with my lambda function. The generated server code doesnt allow me to handle improper input data that I am aware of. It errors before reaching my function for the endpoint.

Rejecting invalid data, and only invoking your handler if the incoming data passes validation, is one of the main benefits of Swift OpenAPI-generated code. Or are you seeing a case when it's rejecting valid data that should have been let through?

Would this be where I create a middleware to implement this functionality?

If there's additional validation you'd like to do before the generated code tries to parse and validate it, yes you could implement a ServerMiddleware and provided it when registering the generated handlers.

I think this is being discussed here #609 Since it is the client that is sending incorrect data, not a server issue but just no way of handling that.

I suspect that's unrelated, your issue is about incoming data into the server, but #609 is about turning errors into specific outgoing data.

[alteredtech]

Rejecting invalid data, and only invoking your handler if the incoming data passes validation, is one of the main benefits of Swift OpenAPI-generated code. Or are you seeing a case when it's rejecting valid data that should have been let through?

I guess you could say It is correctly rejecting invalid data but when it is trying to decode the input, it gets a typemismatch and throws a 500 error. Even though it is not a server error, it is a client error. The testing suite tries the Int64 overflow (so 9,223,372,036,854,775,808 instead of the max 9,223,372,036,854,775,807) and this is what causes the typemismatch.

If there's additional validation you'd like to do before the generated code tries to parse and validate it, yes you could implement a ServerMiddleware and provided it when registering the generated handlers.

its less validation but being able to throw a different error for the client. In the retry example, there is one that if it receives a 500, then wait. I could modify that if the type is a typemismatch, then return a 400 error.

I suspect that's unrelated, your issue is about incoming data into the server, but #609 is about turning errors into specific outgoing data.

hmm I guess I thought it was by these two lines.

E.g. decoding or invalid content type errors should rather be handled as bad requests, as the responsibility to provide a valid request lays on the client side, this is nothing the server can fix.

let statusCode: HTTPResponse.Status = switch self.underlyingError {
    case is DecodingError:
        .badRequest 

[czechboy0]

So if your concern is the HTTP code that's returned by the server when an input is invalid then yes, #609 is the solution.

I understood your issue here as asking for some way to reject input that isn't rejected today by the generated code, which can be done using a ServerMiddleware or by rejecting it in the handler.

In light of this, does it mean we can close this issue and centralize the discussion about the response status code in #609?

[alteredtech]

Awesome. Now that I know that is the solution, then yup I can close this with this comment. Thanks a ton!