Feature request: Add an exceptional case for returning a Pydantic model from path operation functions when its type and the type hint for returned value is the same..

[amirsoroush]

First Check

• I added a very descriptive title here.
• I used the GitHub search to find a similar question and didn't find it.
• I searched the FastAPI documentation, with the integrated search.
• I already searched in Google "How to X in FastAPI" and didn't find any information.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I already checked if it is not related to FastAPI but to Pydantic.
• I already checked if it is not related to FastAPI but to Swagger UI.
• I already checked if it is not related to FastAPI but to ReDoc.

Commit to Help

• I commit to help with one of those options 👆

Example Code

from typing import Self

from fastapi import FastAPI
from pydantic import BaseModel, PositiveInt, model_validator


class Person:
    def __init__(self, name: str, age: int) -> None:
        self.name = name
        self.age = age


class PersonOutput(BaseModel):
    name: str
    age: PositiveInt

    @model_validator(mode="after")
    def log(self) -> Self:
        print("Validation using PersonOutput.")
        return self


app = FastAPI()


@app.get("/")
async def index() -> PersonOutput:
    person = Person(name="foo", age=100)
    return PersonOutput(name=person.name, age=person.age)

Description

In our team, we create a Pydantic model explicitly and return it from the path operation function. The reason is that if we later decide to change one of its fields, the type checker complains about it before runtime.

But here is the problem, FastAPI currently has no idea what the returned object is. It will "re-validate" it using the specified return type, which is obviously unnecessary(by running the above code you'll get "Validation using PersonOutput." printed two times).

A workaround is that I can simply remove the return type ( -> PersonOutput:) but I don't really like it. Ruff (in strict mode) also says: fully annotate your functions. Sometimes I create and return that Pydantic object from an external function so the type hint really helps me ensuring that the object has the correct type. Another workaround is to create and directly return the subclasses of Response. It will work but it requires an extra work to do.

I tracked down the source code and reached this line:

https://github.com/tiangolo/fastapi/blob/master/fastapi/routing.py#L134

If I provide the return type it will re-validate it for the second time.

I think a simple fix for this is to add additional check like:

    if field:
        # if (check to see if field is a pydantic model and is exactly the same as the type of the returned object):
        #     return ...

If the types are the same it means the validation is already done and we have a valid Pydantic object ready to be serialized. The cost would be an additional comparison but it's beneficial for these cases.

Thanks for reading. I'm ready to help if that made sense to you.

Operating System

macOS

Operating System Details

No response

FastAPI Version

0.108.0

Pydantic Version

2.6.3

Python Version

Python 3.11.5

Additional Context

No response

[YuriiMotov]

I also think that this feature would be very useful.

For now you can return Response object directly to avoid second validation, as it's described in the documentation: https://fastapi.tiangolo.com/advanced/response-directly/

from typing import Self

from fastapi import FastAPI, Response
from fastapi.encoders import jsonable_encoder
from fastapi.responses import JSONResponse
from pydantic import BaseModel, PositiveInt, model_validator

class Person:
    def __init__(self, name: str, age: int) -> None:
        self.name = name
        self.age = age

class PersonOutput(BaseModel):
    name: str
    age: PositiveInt

    @model_validator(mode="after")
    def log(self) -> Self:
        print("Validation using PersonOutput.")
        return self

app = FastAPI()

@app.get("/", response_model=PersonOutput)
async def index() -> Response:
    person = Person(name="foo", age=100)

    return JSONResponse(
        content=jsonable_encoder(PersonOutput(name=person.name, age=person.age))
    )

And, if you are sure that your data is JSON-compatible, you can skip jsonable_encoder part:

@app.get("/", response_model=PersonOutput)
async def index() -> Response:
    person = Person(name="foo", age=100)
    return JSONResponse(
        content=PersonOutput(name=person.name, age=person.age).model_dump()
    )

[amirsoroush]

Thanks for the response. Actually we thought about it and so far this is the best thing we can do although it seems too much manual work. After all these are the things that FastAPI itself is taking care of it.

[jereflit]

My personal opinion on this is that you should stick using

@app.get("/", response_model=PersonOutput)
async def index() -> Response:
    person = Person(name="foo", age=100)
    return person

because this is how the FastAPI has been thought to be used at the first place (which is usefull to implicitely convert some returned data to a given model).

Regarding the typing validation (and make you type checker complain in case of mismatch), in this particular case you are checking the type of the object returned by the endpoint. So you should already have non-regression tests ensuring that your API actually returns what is expected.

My point is: endpoint testing is mandatory IMO, so you are safe (of course, detecting problems before running tests would be best).

If you really don't want to have a double validation and keep all the typing (and therefore work with explicit over implicit, you can disable the response_model : https://fastapi.tiangolo.com/tutorial/response-model/?h=response_model#disable-response-model and do this way:

@app.get("/", response_model=None)
async def index() -> PersonOutput:
    person = Person(name="foo", age=100)
    return PersonOutput(name=person.name, age=person.age)

[amirsoroush]

Thanks for the response. I don't think they(my team) are going to agree on implicit creation of Pydantic models because of the mentioned reasons, but the response_model=None trick is satisfactory. Adding this doesn't require much effort.

[YuriiMotov]

But with response_model=None you will not have response model schema in the documentation

[amirsoroush]

Oops. That's really important. I have to uncheck the answer as it introduce another problem beside solving the actual problem.

[jereflit]

Got it. So you end up with either double validation or no type checking. I don't see any other workaround.