--use-type-alias: inline object unions validate defaults through the first branch only

[keyz]

Describe the bug
datamodel-code-generator==0.54.1 generates an incorrect default_factory for inline object unions: it always validates through the first branch.

To Reproduce

Example schema:

{
  "$defs": {
    "A": { "properties": { "type": { "const": "a" } } },
    "B": { "properties": { "type": { "const": "b" } } }
  },
  "properties": {
    "x": {
      "default": { "type": "b" },
      "anyOf": [
        { "$ref": "#/$defs/A" },
        { "$ref": "#/$defs/B" }
      ]
    }
  }
}

Used commandline:

$ datamodel-codegen \
    --input schema.json \
    --input-file-type jsonschema \
    --output out.py \
    --output-model-type pydantic_v2.BaseModel \
    --use-type-alias \
    --target-python-version 3.12

Observed output:

class Model(BaseModel):
    x: A | B | None = Field(default_factory=lambda: A.model_validate({"type": "b"}))

Observed behavior:

• mypy passes
• Model() fails at runtime because {"type": "b"} is validated as A

Expected:

• validate the default against the union and produce B, not hardcode branch 1

[coderabbitai]

🔗 Related PRs

#2840 - Fix x-python-type for Optional container types in anyOf schemas [merged]
#2853 - Fix reuse-model generating type aliases instead of class inheritance [merged]
#2948 - Fix bug in handling of graphql empty list defaults [merged]
#2958 - Fix required list fields ignoring empty default values [merged]
#3012 - Skip default_factory wrapping for non-callable type aliases [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[clawdney]

Hi! I'm interested in helping with this. Could you share more context about the use case?

[github-actions]

📢 Related PR Released: 0.55.0

PR #3040, which references this issue, has been released. See the release notes for details.

Note: This issue was not explicitly closed by the PR.

[butvinm]

I see this was already addressed in #3040 via ValidatedDefault + TypeAdapter, but I think a simpler and more idiomatic approach would be to use Pydantic's built-in validate_default field option.

Instead of:

from pydantic import BaseModel, Field, TypeAdapter

class Model(BaseModel):
    x: A | B | None = Field(
        default_factory=lambda: TypeAdapter(A | B).validate_python({'type': 'b'})
    )

The generated model could be:

from pydantic import BaseModel, Field

class Model(BaseModel):
    x: A | B | None = Field(default={'type': 'b'}, validate_default=True)

Pydantic validates and picks the correct branch at instantiation:

>>> Model().x
B(type='b')

Works the same for type alias unions:

type U = A | B

class Model(BaseModel):
    x: U | None = Field(default={'type': 'b'}, validate_default=True)

>>> Model().x
B(type='b')

The detection logic for when to emit validate_default=True would be the same as the existing _needs_validated_default(), but the output is simpler — no ValidatedDefault class, no TypeAdapter import, no lambda wrapper. Just a native Pydantic mechanism.

[butvinm]

@koxudaxi I drafted PR #3050 implementing this approach. It also subsumes the WrappedDefault mechanism (RootModel scalar defaults like CountType(10)), since validate_default=True handles that natively too. Generated output changes for all fields with model-typed defaults, but runtime behavior is equivalent

[github-actions]

🎉 Released in 0.56.0

The fix/feature from PR #3050 has been included in this release. See the release notes for details.

Thank you for your contribution!