Wrong openapi response model with optional fields

[FArseny]

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 fastapi import FastAPI
from pydantic import BaseModel
from fastapi import Request


class ResponseInfo(BaseModel):
    status: str | None = None
    entry_id: int


app = FastAPI()

@app.post("/info", response_model=ResponseInfo)
async def read_item(request: Request):
    return ResponseInfo(entry_id=10)

Description

After running server i expect to see response model to have optional status, but swagger show it as required.

I checked app.openapi() it returns ... 'required': ['status', 'entry_id']
And check pydantic:
{'properties': {'status': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'title': 'Status'}, 'entry_id': {'title': 'Entry Id', 'type': 'integer'}}, 'required': ['entry_id'], 'title': 'ResponseInfo', 'type': 'object'}

This takes place only in response_model; in request works as expected

Operating System

macOS

Operating System Details

No response

FastAPI Version

0.101.0

Pydantic Version

2.1.1

Python Version

3.11.0

Additional Context

No response

[andrerav]

Seeing the same issue. This will cause problems with response deserialization if you generate a client from this spec in a language such as C#. Pydantic 2.1.1, FastAPI 0.101.0.

[andrerav]

@tiangolo FYI

[commonism]

related #10039

[alexgaspard]

We have the same issue and indeed we are using openapi-generator-cli to generate a client so this impacts us. Is there any workaround?

[andrerav]

@alexgaspard Downgrading to 0.100.0 worked well for me, try that and see if it helps :)

[alexgaspard]

@andrerav Thank you, yes it works! :)

[aravindnujella]

It generates anyOf with request models as well.
#10070

[tiangolo]

Yep, there was a lot of work put to get this new behavior, it's actually more correct, but I just added a feature to allow disabling it if you want to get the old behavior back, it's available since FastAPI 0.102.0 🎉 https://fastapi.tiangolo.com/how-to/separate-openapi-schemas/

[aravindnujella]

@tiangolo Looks like fastapi (v0.103) still generates redundant anyOf schemas for optional fields. I have documented one case where redundant anyOf description is generated here - #10070