- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 228
New behavior around optional nested objects breaks deserialization when explicit null is returned #343
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thanks for filing the bug report! I'll try to get a fix in for this by the end of the week 😊 |
It's certainly possible, that PR does a lot to clean up that code. If you get a chance to check out that branch and confirm, that would be great! I plan on also re-reviewing that PR later this week, but there's been a lot of back and forth on it so far so I don't know how long until it's ready to merge. |
Hey @joshzana now that #332 is done, I took a deeper look at this. Turns out this is actually working as intended. In 0.8.0 we tightened up our In OpenAPI, there is a difference between something being not-required and something being nullable. If something is not required (as is the case with your example), it's possible that it will not be included at all. If something is nullable, it's possible for it to have an explicit {
"title": "ResourceWithOptional",
"type": "object",
"properties": {
"item": { "$ref": "#/components/schemas/ItemResource" }
}
} Where that I've run into this issue quite a bit using FastAPI in the back end and TypeScript in the front end. If something is from pydantic import Field
class ResourceWithOptional(BaseModel):
item: Optional[ItemResource] = Field(None, nullable=True) If you are never going to omit the field, but rather always pass explicit That was a long-winded explanation, but I know this particular facet of OpenAPI can be very confusing, especially when working from Python where there is only 1 type of |
Describe the bug
We use FastAPI as an API server and generate a python client with
open-api-client
that is then used to run integration tests. Our team is using 0.7.3 but I was trying to update to 0.8.0. When doing so, we ran into the following exception running our test suite:I was able to narrow down the problem to handling of
Optional[T]
objects within response models. Here is a minimal repro:To Reproduce
Steps to reproduce the behavior:
resource_with_optional.py
in thefrom_dict
method:Expected behavior
I expect that this allows for an explicit
null
to be returned, as was the case in openapi-python-client==0.7.3, where the generated code looks like this:OpenAPI Spec File
Desktop (please complete the following information):
Additional context
FastAPI has support for excluding nulls from responses with
response_model_exclude_none
but this means changing how our API works to suit the sdk generator, which I would prefer not to have to do.The new behavior I was referring to seems to have come in with #334
The text was updated successfully, but these errors were encountered: