The Fix
pip install pydantic==1.10.14
Based on closed pydantic/pydantic issue #8777 · PR/commit linked
Production note: This usually shows up under retries/timeouts. Treat it as a side-effect risk until you can verify behavior with a canary + real traffic.
@@ -1018,5 +1018,32 @@ except PydanticUserError as exc_info:
```
+## Cannot evaluate type annotation {#unevaluable-type-annotation}
+
+Because type annotations are evaluated *after* assignments, you might get unexpected results when using a type annotation name
repro.py
from pydantic import BaseModel as Base
class Stash(Base):
Name: str
X: int
Y: int
class Listing(Base):
Method: str
Indexed: datetime
Stash: Stash
Account: Account
Price: Price
verify
Re-run the minimal reproduction on your broken version, then apply the fix and re-run.
fix.md
Option A — Upgrade to fixed release\npip install pydantic==1.10.14\nWhen NOT to use: This fix is not applicable if you require the field name to match the type without using an alias.\n\n
Why This Fix Works in Production
- Trigger: return f'{self.__repr_name__()}({self.__repr_str__(", ")})'
- Mechanism: Field names cannot clash with types in Pydantic models, causing self-referential issues
- Why the fix works: Raises an error when field names clash with types, addressing the issue of self-referential field names in Pydantic models. (first fixed release: 1.10.14).
Production impact:
- If left unfixed, the same config can fail only in production (env differences), causing startup failures or partial feature outages.
Why This Breaks in Prod
- Shows up under Python 3.11 in real deployments (not just unit tests).
- Field names cannot clash with types in Pydantic models, causing self-referential issues
- Surfaces as: File "/Users/canercetin/Library/Caches/pypoetry/virtualenvs/zurna-backend-VoMrHkaz-py3.11/lib/python3.11/site-packages/pydantic/_internal/_repr.py", line 82, in __repr__
Proof / Evidence
- GitHub issue: #8777
- Fix PR: https://github.com/pydantic/pydantic/pull/8243
- First fixed release: 1.10.14
- Reproduced locally: No (not executed)
- Last verified: 2026-02-09
- Confidence: 0.95
- Did this fix it?: Yes (upstream fix exists)
- Own content ratio: 0.41
Discussion
High-signal excerpts from the issue thread (symptoms, repros, edge-cases).
“StashRepr: Optional[Stash] = Field(default=None, alias="Stash") I know that I can just fix this by adding alias but come on. Writing Stash everywhere would be hella…”
“@caner-cetin, Right - we implemented this warning here: https://github.com/pydantic/pydantic/pull/8243, so this behavior is expected and intentional”
“Duplicate of https://github.com/pydantic/pydantic/issues/8240”
“but come oooon, think how cool it would be to do without alias @sydney-runkle”
Failure Signature (Search String)
- return f'{self.__repr_name__()}({self.__repr_str__(", ")})'
Error Message
Stack trace
error.txt
Error Message
-------------
File "/Users/canercetin/Library/Caches/pypoetry/virtualenvs/zurna-backend-VoMrHkaz-py3.11/lib/python3.11/site-packages/pydantic/_internal/_repr.py", line 82, in __repr__
return f'{self.__repr_name__()}({self.__repr_str__(", ")})'
^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/canercetin/Library/Caches/pypoetry/virtualenvs/zurna-backend-VoMrHkaz-py3.11/lib/python3.11/site-packages/pydantic/_internal/_repr.py", line 55, in __repr_str__
return join_str.join(repr(v) if a is None else f'{a}={v!r}' for a, v in self.__repr_args__())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/canercetin/Library/Caches/pypoetry/virtualenvs/zurna-backend-VoMrHkaz-py3.11/lib/python3.11/site-packages/pydantic/_internal/_repr.py", line 55, in <genexpr>
return join_str.join(repr(v) if a is None else f'{a}={v!r}' for a, v in self.__repr_args__())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/canercetin/Library/Caches/pypoetry/virtualenvs/zurna-backend-VoMrHkaz-py3.11/lib/python3.11/site-packages/pydantic/fields.py", line 559, in __repr_args__
yield 'annotation', _repr.PlainRepr(_repr.display_as_type(self.annotation))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/canercetin/Library/Ca
... (truncated) ...
Minimal Reproduction
repro.py
from pydantic import BaseModel as Base
class Stash(Base):
Name: str
X: int
Y: int
class Listing(Base):
Method: str
Indexed: datetime
Stash: Stash
Account: Account
Price: Price
Environment
- Python: 3.11
- Pydantic: 2
What Broke
Users encounter errors when trying to define fields with the same name as their types.
Why It Broke
Field names cannot clash with types in Pydantic models, causing self-referential issues
Fix Options (Details)
Option A — Upgrade to fixed release Safe default (recommended)
pip install pydantic==1.10.14
When NOT to use: This fix is not applicable if you require the field name to match the type without using an alias.
Use when you can deploy the upstream fix. It is usually lower-risk than long-lived workarounds.
Fix reference: https://github.com/pydantic/pydantic/pull/8243
First fixed release: 1.10.14
Last verified: 2026-02-09. Validate in your environment.
When NOT to Use This Fix
- This fix is not applicable if you require the field name to match the type without using an alias.
Verify Fix
verify
Re-run the minimal reproduction on your broken version, then apply the fix and re-run.
Did This Fix Work in Your Case?
Quick signal helps us prioritize which fixes to verify and improve.
Prevention
- Add a CI check that diffs key outputs after upgrades (OpenAPI schema snapshots, JSON payload shapes, CLI output).
- Upgrade behind a canary and run integration tests against the canary before 100% rollout.
Version Compatibility Table
| Version | Status |
|---|---|
| 1.10.14 | Fixed |
Related Issues
No related fixes found.
Sources
We don’t republish the full GitHub discussion text. Use the links above for context.