Flop exceptions related to invalid inputs should result in 400 Bad Request

[a3kov]

Is your feature request related to a problem? Please describe. Currently if you pass invalid filter value, for example, you get error 500. 400 would be more appropriate.

Describe the solution you'd like Exceptions should have plug_status property set:

defexception [:message, plug_status: 400]

Describe alternatives you've considered

Additional context

[woylie]

I'm not sure setting the status to 400 for library users is the right choice in all cases. We don't know how the library is used.

• invalid parameters received via form (query string, form data): yes, should be 400
• invalid parameters received via API request: also 400
• hard-coded invalid parameters: should be 500
• invalid parameters resulting from a bug in converting user-given parameters into the Flop format: 500, since the parameters passed to the server are valid, but the internal conversion logic is broken
• a field that is documented in the API documentation as filterable is not marked filterable in the Ecto schema: not the user's fault, 500; if the API request is validated with a GraphQL input type or JSON schema, it is probably more likely that it's a server-side error than a client-side error

Library users have the option to set the status code by deriving the Plug.Exception protocol:

defimpl Plug.Exception, for: Flop.InvalidParamsError do
  def status(_exception), do: 400
  def actions(_exception), do: []
end

Maybe it's better to leave this up to the user instead of making a decision for them.

[a3kov]

I am fine with the solution where I need to implement the protocol myself, thanks!

Only want to note that it's the same with HTTP requests in general: Bad Request doesn't always come from the user error. It's just a way for the server to say, "hey, you sent me some invalid data in the request". It doesn't always mean that the user is the source of the error.

[woylie]

The specification uses the phrasing "perceived to be a client error":

The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

(source)

[woylie]

In the case of a filter for a not filterable field, a 422 might be more appropriate, since the request was syntactically correct.