You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Pydantic aliases gain unwanted internal-name properties #237
0.64.0, current main d34b372556392f9bfb49e8590d2c4f253c103309; Python 3.13.13 / Pydantic 2.14.0 / macOS arm64.
Describe the bug
When using the documented Pydantic-model schema integration with an optional aliased field, schema normalization adds a second property under the internal Python field name. Repairs can consequently return data that the original Pydantic model rejects, even when extra="forbid" is set.
schema_from_input iterates model_fields by Python name when adding defaults, while Pydantic's validation JSON Schema uses aliases. In the example below the schema initially contains only displayName; normalization adds display_name, and repair inserts that unwanted field.
This affects typed structured-output processing: the repaired dict cannot pass the same model's model_validate step. Found by code inspection and reproduced with the actual Pydantic model/API; this is not a report of production usage.
{'displayName': 'Alice', 'display_name': 'unknown'}
pydantic_core.ValidationError: 1 validation error for Payload
display_name
Extra inputs are not permitted [type=extra_forbidden, input_value='unknown', input_type=str]
The same problem occurs when valid JSON needs scalar coercion, e.g. '{"displayName": 42}'.
Expected behavior
Return {'displayName': 'Alice'}, which validates against Payload, without adding a Python-name property absent from the original JSON Schema. Default/default-factory augmentation should target the property's validation alias when present, preserving Pydantic's schema names rather than widening extra="forbid".
I intend to fix the field-to-property mapping and add a focused regression covering repaired output and downstream model validation. Codex assisted with investigation and local reproduction.
The focused regression fails in all three cases on unchanged main, including with the final dependency versions, and passes with the fix. Final full suite: 406 passed, 1 skipped; all configured pre-commit hooks pass, including 100% source coverage, type checks and security checks. The required hooks' lockfile/tool updates and the patch/citation version alignment are retained per AGENTS.md.
I couldn't open the PR: GitHub reports that this repository's pull_request_creation_policy is collaborators_only. I'll leave the tested branch available here for maintainer review rather than attempt another submission route. Codex assisted with the implementation and local validation.
Activity
HuaTNA commentedon Oct 17, 2026
The fix is ready on HuaTNA:fix-pydantic-schema-alias-defaults at
67fc06bd47f193d13d13ab9f0e779e5115421b6c(compare).The focused regression fails in all three cases on unchanged main, including with the final dependency versions, and passes with the fix. Final full suite: 406 passed, 1 skipped; all configured pre-commit hooks pass, including 100% source coverage, type checks and security checks. The required hooks' lockfile/tool updates and the patch/citation version alignment are retained per
AGENTS.md.I couldn't open the PR: GitHub reports that this repository's
pull_request_creation_policyiscollaborators_only. I'll leave the tested branch available here for maintainer review rather than attempt another submission route. Codex assisted with the implementation and local validation.