Skip to content

[Bug]: Pydantic aliases gain unwanted internal-name properties #237

Closed

Description

@HuaTNA

Version of the library

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.

How to reproduce

from pydantic import BaseModel, ConfigDict, Field
from json_repair import loads

class Payload(BaseModel):
    model_config = ConfigDict(extra="forbid")
    display_name: str = Field(default="unknown", alias="displayName")

repaired = loads('{displayName: "Alice"}', schema=Payload)
print(repaired)
Payload.model_validate(repaired)

Actual:

{'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.

Activity

  1. HuaTNA commented on Oct 17, 2026

    @HuaTNA
    Author

    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_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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions