🐛 Fix non-deterministic openapi spec in case of duplicated model names#14797
Closed
igoyak wants to merge 2 commits intofastapi:masterfrom
Closed
🐛 Fix non-deterministic openapi spec in case of duplicated model names#14797igoyak wants to merge 2 commits intofastapi:masterfrom
igoyak wants to merge 2 commits intofastapi:masterfrom
Conversation
igoyak
force-pushed
the
fix-nondeterministic-openapi
branch
4 times, most recently
from
90a6bb7 to
4412526
Compare
YuriiMotov
reviewed
Feb 2, 2026
Member
YuriiMotov
left a comment
YuriiMotov
left a comment
There was a problem hiding this comment.
@igoyak, thanks for your interest and efforts!
I think we should think if we can avoid exposing the path of the module.
I can see the following approaches:
- In case of name ambiguity, generate names this way (with module path), but issue a warning. So that developers could notice it and prevent the leakage of the internal implementation
- Use the hash of module path instead of path itself (still not very secure)
- Use one of methods above, but provide the way to override the way unique components names are created (similar to
generate_unique_id_functionparameter)
@igoyak, what do you think?
igoyak
force-pushed
the
fix-nondeterministic-openapi
branch
2 times, most recently
from
8562605 to
fb50eda
Compare
v0.128.0 introduced non-deterministic openapi spec schema naming in the case of multiple pydantic models with the same name. Commit [e300630](fastapi@e300630#diff-1086603fdd56511aafd1d279396b142b803e48164327148e6de26cef4cdaed81L504) removed the check for conflicting names. The component names two classes named `User` would randomly be either ``` User tests__test_duplicate_model_names_openapi__b__model__User ``` ``` tests__test_duplicate_model_names_openapi__a__model__User User ``` With this change, we reintroduce the conflict check to always use a hash of the fully qualified names in case of conflict.
igoyak
force-pushed
the
fix-nondeterministic-openapi
branch
from
fb50eda to
748840e
Compare
Member
|
@igoyak, thanks! Let's wait for Sebastian to review it and validate the idea. I still think that we should emit a warning and provide a way for developers to override the function that is used for component names generation |
YuriiMotov
changed the title
Author
|
Looks like this bugfix was essentially done (accidentally?) in cf55bad so closing this. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
v0.128.0 introduced non-deterministic openapi spec schema naming in the case of multiple pydantic models with the same name.
Commit e300630 removed the check for conflicting names.
The component names two classes named
Userwould randomly be eitherWith this change, we reintroduce the conflict check to always use fully qualified names in case of conflict.