-
First Check
Commit to Help
Example Codeimport json
from pydantic import BaseModel, Field
from fastapi import FastAPI
from fastapi import __version__ as fastapi_version
class Model(BaseModel):
field: str = Field("foo", const=True)
app = FastAPI(title=f"Created with FastAPI v{fastapi_version}")
@app.get("/", response_model=Model)
def root():
return Model(field="foo")
print(json.dumps(Model.schema(), indent=2))
print(json.dumps(app.openapi(), indent=2))DescriptionWith Here is a diff between the schema created for v0.65.2 vs v0.68 (also tested with 0.66, 0.67 with the same results). // ...
},
"components": {
"schemas": {
"Model": {
"title": "Model",
"type": "object",
"properties": {
"field": {
"title": "Field",
"type": "string",
+ "const": "foo"
}
// ...This regression is caused by the addition of While I would also like to be able to use extension keys (with the appropriate Operating SystemLinux Operating System DetailsNo response FastAPI Version0.68.0 Python Version3.8.5 Additional ContextI've made two gists for the OpenAPI schemas from v0.68.0 and v0.65.2:
You can pass the raw json through the online swagger validator to verify:
|
Beta Was this translation helpful? Give feedback.
Replies: 20 comments
-
|
This addition of
This is obviously because all of pydantics |
Beta Was this translation helpful? Give feedback.
-
|
Turns out the custom BaseModel was adding some stuff to 'extra' in FieldInfo that it was using for its own internals. Now that |
Beta Was this translation helpful? Give feedback.
-
Could you elaborate please? Which custom BaseModel? This sounds like a different (but related) issue to what I am facing (where the OpenAPI is generated without error but the field names themselves are not valid OpenAPI). |
Beta Was this translation helpful? Give feedback.
-
|
It was a custom BaseModel and Field() override that added a few things to extra. In older FastAPI versions those were ignored, which was the desired effect. Now they show up due to |
Beta Was this translation helpful? Give feedback.
-
|
Right, I'm with you now.
My suggested fix was something like this, i.e. allowing any
I would've thought this would be quite important to fix for anyone relying on FastAPI for OpenAPI schema generation, but it doesn't seem like many other users are running into this. Due to the lack of uptake on this issue, perhaps it would not be too rude to attempt to summon @tiangolo to get his thoughts... |
Beta Was this translation helpful? Give feedback.
-
|
My guess is, if people are using extra and pumping in invalid parameters that get piped to extra, their OpenAPI spec IS invalid, they just don't know it. I didn't until you mentioned the swagger validator. I ran my .json through https://apitools.dev/swagger-parser/online/ and it was definitely invalid because of my extra stuff not using |
Beta Was this translation helpful? Give feedback.
-
|
Not sure if this helps with your particular use case...as a workaround. Obviously defaulting That's basically what I did with my custom |
Beta Was this translation helpful? Give feedback.
-
|
When using custom extra attributes on fields, which are used internally for different kinds of data processing, these values are now exposed in the api schema. To give some context: I'm using fastapi with django. To map pydantic model fields to a django model field, an argument from django.db import models
from pydantic import BaseModel
class MyDBModel(models.Model):
id = models.CharField(primary_key=True, max_length=16)
class MyModel(BaseModel):
id: str = Field(orm_field=MyDBModel.id)Without patching fastapi.openapi.models.Schema's Config setting extra = 'ignore' (as it was pre 0.66.0), a infinite recursion ocurrs when rendering the openapi.json As the OpenAPI Spec only allows custom attributes with a |
Beta Was this translation helpful? Give feedback.
-
|
Just tested again and this bug is still affecting v0.75.1. It would be great to get some confirmation that a fix to FastAPI would be useful, perhaps following @mreschke's workaround above. I fear that many users are producing invalid OpenAPI schemas without realising. |
Beta Was this translation helpful? Give feedback.
-
|
Is there any chance you could confirm this is a bug @tiangolo, 1 year on? If not, I am happy to prepare a docs PR that tries to explain the issue for other confused users. Given the (deserved) popularity of FastAPI I think this is unfortunately poisoning the OpenAPI ecosystem with invalid schemas! Whilst @mreschke's fix above does generate the correct OpenAPI spec, I think that it ends up disabling the pydantic validation (of e.g. A nice fix would be to capture this at the pydantic level with a new Unfortunately, as we are 1 year on, this may break things for people relying on extra fields in their non-standard OpenAPI schemas. |
Beta Was this translation helpful? Give feedback.
-
|
Any progress on this one? |
Beta Was this translation helpful? Give feedback.
-
I made a pull request to the docs warning people about this (#4846) but it hasn't gotten any traction either, I wonder if anyone else who has encountered this problem has feedback for that PR or better suggestions for how to deal with it? |
Beta Was this translation helpful? Give feedback.
-
|
Hey all! Some additional info: Pydantic generates JSON Schema, and that is re-used by OpenAPI. But OpenAPI 3.0.x is based on an old version of JSON Schema that didn't have So, about Now, about extra fields included by default in the output JSON Schema, I hope a future version of Pydantic will have something like |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for breaking it down @tiangolo! |
Beta Was this translation helpful? Give feedback.
-
|
any movement on this? We're also stuck with an autogenerated openapi spec that seems invalid. From the comment above it's not clear to me how what users should do. What are the mitigation steps? Downgrade fastapi if needing a valid openapi spec? |
Beta Was this translation helpful? Give feedback.
-
|
Here's the slightly kludgey way we got around it @trondhindenes, in case it is useful to you: https://github.com/Materials-Consortia/optimade-python-tools/pull/1131/files Basically:
|
Beta Was this translation helpful? Give feedback.
-
|
awesome, thanks for that @ml-evs ! |
Beta Was this translation helpful? Give feedback.
-
|
Just a quick note that Pydantic v2 will have its own independent field That will at least help understand and debug these use cases better. 🤓 |
Beta Was this translation helpful? Give feedback.
-
|
Assuming the original need was handled, this will be automatically closed now. But feel free to add more comments or create new issues or PRs. |
Beta Was this translation helpful? Give feedback.
-
|
Digging up an old discussion as it seems relevant. This is with pydantic 2.10.6 and fastapi 0.115.8. Ran into this issue where our Model needs to have a 'primary_key' attribute as field for business reasons, but when we generate the OpeanAPI spec file, it primary_key field is listed as part of the models property fields. It's an issue as when we try to upload it to our auto documentation generator site, it bails out on us, complaining that the openapi spec is not correct (giving the error "Object includes not allowed fields", from the Swagger online editor). We've gotten around it by doing janky things in our document generator code like Is there a more appropriate fix for this that I've missed? I was thinking that pydantic 2 would only send in fields that were apart of |
Beta Was this translation helpful? Give feedback.
Just a quick note that Pydantic v2 will have its own independent field
json_schema_extrainstead of taking everything else and putting it in the JSON Schema output. 🎉That will at least help understand and debug these use cases better. 🤓