Regression in OpenAPI schema generation with multiple Enums having the same name but different enum members #1857
Description
Bug
Output of python -c "import pydantic.utils; print(pydantic.utils.version_info())":
pydantic version: 1.6.1
pydantic compiled: True
install path: /Users/philipp/Downloads/env/lib/python3.7/site-packages/pydantic
python version: 3.7.6 (default, Dec 30 2019, 19:38:28) [Clang 11.0.0 (clang-1100.0.33.16)]
platform: Darwin-19.3.0-x86_64-i386-64bit
optional deps. installed: []
At first, thank you all for this incredible piece of software!
As of #1432 enums are included as separate models and and are referenced in all locations. In the case of multiple enums with the same name but different enum members, located in different modules, only one of these enums is included in the OpenAPI schema.
File other.py:
from enum import Enum
from pydantic import BaseModel
class SomeEnum(str, Enum):
d = "d"
e = "e"
f = "f"
class SomeOtherModel(BaseModel):
some_enum: SomeEnumFile main.py:
from enum import Enum
from pydantic import BaseModel
from other import SomeOtherModel
class SomeEnum(str, Enum):
a = "a"
b = "b"
c = "c"
class MainModel(BaseModel):
some_enum: SomeEnum
some_other_model: SomeOtherModel
if __name__ == "__main__":
print(MainModel.schema_json())Executing main.py produces the following schema:
{
"title": "MainModel",
"type": "object",
"properties": {
"some_enum": {
"$ref": "#/definitions/SomeEnum"
},
"some_other_model": {
"$ref": "#/definitions/SomeOtherModel"
}
},
"required": [
"some_enum",
"some_other_model"
],
"definitions": {
"SomeEnum": {
"title": "SomeEnum",
"description": "An enumeration.",
"enum": [
"d",
"e",
"f"
],
"type": "string"
},
"SomeOtherModel": {
"title": "SomeOtherModel",
"type": "object",
"properties": {
"some_enum": {
"$ref": "#/definitions/SomeEnum"
}
},
"required": [
"some_enum"
]
}
}
}
Only the Enum from other.py is included and the schema now contains invalid supported enum values for MainModel.some_enum.
Before #1432 this works as expected because the enum values are included as-is. Ideally pydantic should handle this case by prefixing different enums with the same name in the OpenAPI schema. I've applied a workaround to my application code by changing the name of conflicting enums but I only detected this new behaviour by having a CI Pipeline step that checks for breaking OpenAPI changes.