_validate_request should raise ValidationError

[felixhummel]

_validate_request should not run abort(), but raise a ValidationError in order to better support centralized error handling.

Background

We use Pydantic models extensively, both in requests handled by flask-openapi

def using_request_body(body: MyPydanticModel):
    pass

... as well as manually ¹

def plain_model_validate():
    ...
    MyPydanticModel.model_validate(request.json)

The Problem

The problem occurs when we try to handle ValidationErrors centrally using @errorhandler like so

@a.errorhandler(ValidationError)
def handle_validation_error(e):
    content = validation_error_to_json(e)
    response = make_response(content, 400)
    response.content_type = 'application/json'
    return response

This works for plain_model_validate, but not for using_request_body, because of the aforementioned call to abort() raises an HTTPException instead of a ValidationError.

Workaround

We currently work around this by raising in the validation_error_callback (before abort() is called) like so:

def _re_raise(e: Exception):
    raise e

app = OpenAPI(..., validation_error_callback=_re_raise)

Footnotes

1. usually in another layer, here in-view for brevity ↩

[luolingchun]

I understand the exception handling you mentioned, and I can summarize it into three approaches:

1. Using a decorator

@app.errorhandler(ValidationError)
def validation_error_callback(e: ValidationError):
    content = validation_error_to_json(e)
    response = make_response(content, 400)
    response.content_type = 'application/json'
    return response

2. Using a registrar

app.register_error_handler(400, validation_error_callback)

3. Using abort

abort(validation_error_callback(e))

By default, I use abort. But I don't mean to say that one approach is better than another. Instead, flask-openapi provides a default way to handle ValidationError, allowing developers to customize it by defining their own validation_error_callback.

Consider that if a default ValidationError handling mechanism were not provided, every developer would have to handle ValidationError on their own, which is clearly not user-friendly.

[felixhummel]

... allowing developers to customize it by defining their own validation_error_callback.

I like the idea of having a hook a lot, because that is how my workaround works. 👍

Consider that if a default ValidationError handling mechanism were not provided, every developer would have to handle ValidationError on their own, which is clearly not user-friendly.

What would happen if we did not wrap the validation_error_callback in abort(), e.g.

def _validate_request(
    header: Type[BaseModel] | None = None,
    cookie: Type[BaseModel] | None = None,
    path: Type[BaseModel] | None = None,
    query: Type[BaseModel] | None = None,
    form: Type[BaseModel] | None = None,
    body: Type[BaseModel] | None = None,
    path_kwargs: dict[Any, Any] | None = None,
) -> dict:
    """
    ...
    """

    # Dictionary to store func kwargs
    func_kwargs: dict = {}

    # Validate header, cookie, path, and query parameters
    if header:
        _validate_header(header, func_kwargs)
    if cookie:
        _validate_cookie(cookie, func_kwargs)
    if path:
        _validate_path(path, path_kwargs or {}, func_kwargs)
    if query:
        _validate_query(query, func_kwargs)
    if form:
        _validate_form(form, func_kwargs)
    if body:
        _validate_body(body, func_kwargs)

    return func_kwargs

My guess is that Flask's default error handling would take over and return a 500 by default.

Users could handle this easily by registering an error handler like so:

@a.errorhandler(ValidationError)
def handle_validation_error(e):
    ...

I understand that a transition from validation_error_callback to this style of customization would bring challenges, but I believe that the gains in readability and flexibility could make this tradeoff worthwhile.