Validation with dataclass

[dineshbvadhia]

A simple function to validate a string using a dataclass:

def validate_string(obj: object):
    if is_str(obj):
        mystring = obj
    else:
        raise RequestValidationError(f'The mystring {obj} is not valid.')

1. The dataclass. Input is the integer 123

@dataclass
class ValidateString:
    mystring: str

response.json: {'type': 'request-validation-failed', 'title': 'Request validation error.', 'status': 422, 'errors': [{'type': 'string_type', 'loc': ['body', 'request_type'], 'msg': 'Input should be a valid string', 'input': 123}]}

2. Change the dataclass type for mystring to Optional[str|int]. Input is the integer 123

@dataclass
class ValidateString:
    mystring: Optional[str|int]

# obj = 123
response.json: {'type': 'request-validation-failed', 'title': 'Request validation error.', 'status': 422, 'errors': 'The mystring 123 is not valid.'}

The # 2 response is what I would expect. It looks like in # 1, the dataclass error overrides the RequestValidationError message in the code.

The solution is to change the dataclass type of objects to be validated to Any but still a bit odd.

[EdgyEdgemond]

Firstly, this is more a question for fastapi/pydantic repositories. It is unrelated to error handling.

But 1, is the more correct code I would say here, let pydantic validate your inputs. The joy of fastapi/pydantic is not having to check for valid input types and letting the system raise for you.

It is occurring because you have told fastapi you expect a string, and it is checking (and failing) before you hit your internal code that then checks the data type to raise your custom RequestValidationError. I would also recommend not raising starlette.RequestValidationError as you are then raising it in a format it is not intended to be used in (as you can see from the standard format of the error compared to your expected format).

Essentially your internal check is made redundant by the external pydantic check. If mystring can be an integer in some cases and not others, then I would create two different classes one that accepts str and one str | int and do logic based on str/int in the case where an int is allowed.

If it is not allowed and you only want strings, then there is no need for the type check and just let fastapi pydantic your inputs.

[EdgyEdgemond]

no worries, if you want to validate using pydantic look at model and field validators, then the logic is contained with the schema rather than separate from it.

https://docs.pydantic.dev/latest/concepts/validators/

But would also recommend relying on pydantic validation errors rather than hand rolling them, adds to the complexity and maintenance of your application :)

[EdgyEdgemond]

Would also still recommend switching to a custom 422 error as it will put your error message in "details" like other raised errors. RequestValidationError is a special case with "errors" in the usual starlette/fastapi format. Differing from that would make client side logic a little harder to write as you'd need to detect if errors is a string rather than a dict in this one case.

Within the context of fastapi_problem one of the intended outcomes is consistent error formatting per error type.

[dineshbvadhia]

I used pydantic v1 with fastapi ages ago which didn't work out. Hand rolled my own validation which does the job mostly. Now onto pydantic v2 :(

Actually, I need to be consistent with the error 1 formatting above ie.

response.json: {'type': 'request-validation-failed', 'title': 'Request validation error.', 'status': 422, 'errors': [{'type': 'string_type', 'loc': ['body', 'request_type'], 'msg': 'Input should be a valid string', 'input': 123}]}

I'll revisit pydantic v2 plus switch to a custom 422 error to get the error messages in details.

[EdgyEdgemond]

pydantic is baked into fastapi essentially, but definitely make use of v2 as that is the default version in fastapi these days.

To get consistent error messages like that, you can just reply on well defined schemas for your endpoint inputs

[dineshbvadhia]

Defined schemas are delivering consistent error messages :)

Validation with Pydantic v2 will have to wait as a lot invested in the hand-rolled version.

Thanks again.