The Fix
pip install pydantic==2.7.3
Based on closed pydantic/pydantic issue #9472 · PR/commit linked
Production note: Most teams hit this during upgrades or environment changes. Roll out with a canary and smoke critical endpoints (health, OpenAPI/docs) before 100%.
@@ -56,10 +56,10 @@ class _FromFieldInfoInputs(typing_extensions.TypedDict, total=False):
examples: list[Any] | None
exclude: bool | None
- gt: float | None
- ge: float | None
- lt: float | None
repro.py
from datetime import timedelta
from pydantic import BaseModel, Field
class Duration(BaseModel):
td: timedelta = Field(timedelta(0), gt=timedelta(0))
Duration(td=timedelta(seconds=1))
Duration(td=timedelta(seconds=-1))
# ValidationError: 1 validation error for Duration
# td
# Input should be greater than 0 seconds [type=greater_than, input_value=datetime.timedelta(days=-1), input_type=timedelta]
# For further information visit https://errors.pydantic.dev/2.7/v/greater_than
# This is all perfectly valid code, but Pyright (and I assume also mypy) complains about the type signature
# $ pyright example.py
# /home/bjmc/Sandbox/example.py
# /home/bjmc/Sandbox/example.py:6:44 - error: Argument of type "timedelta" cannot be assigned to # parameter "gt" of type "float | None" in function "Field"
# Type "timedelta" is incompatible with type "float | None"
# "timedelta" is incompatible with "float"
# "timedelta" is incompatible with "None" (reportArgumentType)
# 1 error, 0 warnings, 0 informations
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==2.7.3\nWhen NOT to use: This fix should not be used if strict float validation is required.\n\n
Why This Fix Works in Production
- Trigger: In actual use, the validation works correctly as expected with `timedelta()` instances, but static type checkers (at least Pyright) object.
- Mechanism: The type signature for Field() validators was too restrictive, allowing only float or None
- Why the fix works: Updates the type signatures in Field() to allow for timedelta in gt/lt/gte/lte validators, addressing issue #9472. (first fixed release: 2.7.3).
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.10 in real deployments (not just unit tests).
- The type signature for Field() validators was too restrictive, allowing only float or None
- Production symptom (often without a traceback): In actual use, the validation works correctly as expected with `timedelta()` instances, but static type checkers (at least Pyright) object.
Proof / Evidence
- GitHub issue: #9472
- Fix PR: https://github.com/pydantic/pydantic/pull/9484
- First fixed release: 2.7.3
- Reproduced locally: No (not executed)
- Last verified: 2026-02-09
- Confidence: 0.85
- Did this fix it?: Yes (upstream fix exists)
- Own content ratio: 0.46
Discussion
High-signal excerpts from the issue thread (symptoms, repros, edge-cases).
“@bjmc, Hmm, I'm intrigued - feel free to open a PR and I can review. I don think it could be good to offer more…”
“Seems reasonable to use the comparison protocols, internally Pydantic uses the functions defined in pydantic._internal._validators (e.g”
“Let's go with the annotated_types protocols”
“I agree that annotated_types is better since it's already a dependency.”
Failure Signature (Search String)
- In actual use, the validation works correctly as expected with `timedelta()` instances, but static type checkers (at least Pyright) object.
- Update: I've added some notes to your PR re testing + some change requests!
Copy-friendly signature
signature.txt
Failure Signature
-----------------
In actual use, the validation works correctly as expected with `timedelta()` instances, but static type checkers (at least Pyright) object.
Update: I've added some notes to your PR re testing + some change requests!
Error Message
Signature-only (no traceback captured)
error.txt
Error Message
-------------
In actual use, the validation works correctly as expected with `timedelta()` instances, but static type checkers (at least Pyright) object.
Update: I've added some notes to your PR re testing + some change requests!
Minimal Reproduction
repro.py
from datetime import timedelta
from pydantic import BaseModel, Field
class Duration(BaseModel):
td: timedelta = Field(timedelta(0), gt=timedelta(0))
Duration(td=timedelta(seconds=1))
Duration(td=timedelta(seconds=-1))
# ValidationError: 1 validation error for Duration
# td
# Input should be greater than 0 seconds [type=greater_than, input_value=datetime.timedelta(days=-1), input_type=timedelta]
# For further information visit https://errors.pydantic.dev/2.7/v/greater_than
# This is all perfectly valid code, but Pyright (and I assume also mypy) complains about the type signature
# $ pyright example.py
# /home/bjmc/Sandbox/example.py
# /home/bjmc/Sandbox/example.py:6:44 - error: Argument of type "timedelta" cannot be assigned to # parameter "gt" of type "float | None" in function "Field"
# Type "timedelta" is incompatible with type "float | None"
# "timedelta" is incompatible with "float"
# "timedelta" is incompatible with "None" (reportArgumentType)
# 1 error, 0 warnings, 0 informations
Environment
- Python: 3.10
- Pydantic: 2
What Broke
Static type checkers raised errors for valid timedelta inputs in Field() constraints.
Why It Broke
The type signature for Field() validators was too restrictive, allowing only float or None
Fix Options (Details)
Option A — Upgrade to fixed release Safe default (recommended)
pip install pydantic==2.7.3
When NOT to use: This fix should not be used if strict float validation is required.
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/9484
First fixed release: 2.7.3
Last verified: 2026-02-09. Validate in your environment.
When NOT to Use This Fix
- This fix should not be used if strict float validation is required.
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 |
|---|---|
| 2.7.3 | Fixed |
Related Issues
No related fixes found.
Sources
We don’t republish the full GitHub discussion text. Use the links above for context.