Pydantic Revisit cases where `__pydantic_private_

The Fix

pip install pydantic==2.7.1

Based on closed pydantic/pydantic issue #9282 · 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%.

Open PR/Commit

@@ -721,7 +721,7 @@ def __copy__(self: Model) -> Model:
         _object_setattr(m, '__pydantic_fields_set__', copy(self.__pydantic_fields_set__))
 
-        if self.__pydantic_private__ is None:
+        if not hasattr(self, '__pydantic_private__') or self.__pydantic_private__ is None:
             _object_setattr(m, '__pydantic_private__', None)

fix.md

Option A — Upgrade to fixed release\npip install pydantic==2.7.1\nWhen NOT to use: This fix should not be applied if the model relies on the original behavior of `__pydantic_private__` being None.\n\nOption C — Workaround\nhas been to run on all such retrieved instances, after retrieval, a `model_post_init` function (which doesn't seem to get called by SQLModel). The question is: why does the `model_post_init` not get called when querying through SQLModel? Would it be possible to make it impossible to miss in various usages of the class?\nWhen NOT to use: This fix should not be applied if the model relies on the original behavior of `__pydantic_private__` being None.\n\n

Why This Fix Works in Production

Trigger: Instances loaded from the DB had `__pydantic_private__` set to None, leading to missing private attributes.
Mechanism: The `__pydantic_private__` attribute was inconsistently set to None or an empty dict, causing potential AttributeErrors
Why the fix works: Addresses the handling of the `__pydantic_private__` attribute in various methods to prevent AttributeError when model_copy is called. (first fixed release: 2.7.1).

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

The `__pydantic_private__` attribute was inconsistently set to None or an empty dict, causing potential AttributeErrors
Production symptom (often without a traceback): Instances loaded from the DB had `__pydantic_private__` set to None, leading to missing private attributes.

Proof / Evidence

GitHub issue: #9282
Fix PR: https://github.com/pydantic/pydantic/pull/9168
First fixed release: 2.7.1
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.77

Discussion

High-signal excerpts from the issue thread (symptoms, repros, edge-cases).

Jump to Sources Open on GitHub

“@Seluj78 Thanks, SQLModel does a lot of black magic to make things _mostly_ work, including bypassing details of our regular model instance construction, so we…”

@DouweM · 2025-04-28 · source

“Hello, any news on this ? We're currently having this problem while superclassing SQModel”

@Seluj78 · 2025-04-09 · source

“@Seluj78 Can you explain in more detail when you're running into this and what issues it's causing?”

@DouweM · 2025-04-25 · source

“> I wouldn't recommend using it in production. No comment x) We'll see about opening an issue on SQLModel's repo and link it here as…”

@Seluj78 · 2025-04-28 · source

Failure Signature (Search String)

Instances loaded from the DB had `__pydantic_private__` set to None, leading to missing private attributes.

Copy-friendly signature

signature.txt

Failure Signature
-----------------
Instances loaded from the DB had `__pydantic_private__` set to None, leading to missing private attributes.

Error Message

Signature-only (no traceback captured)

error.txt

Error Message
-------------
Instances loaded from the DB had `__pydantic_private__` set to None, leading to missing private attributes.

What Broke

Instances loaded from the DB had `__pydantic_private__` set to None, leading to missing private attributes.

Why It Broke

The `__pydantic_private__` attribute was inconsistently set to None or an empty dict, causing potential AttributeErrors

Fix Options (Details)

Option A — Upgrade to fixed release Safe default (recommended)

pip install pydantic==2.7.1

When NOT to use: This fix should not be applied if the model relies on the original behavior of `__pydantic_private__` being None.

Use when you can deploy the upstream fix. It is usually lower-risk than long-lived workarounds.

Option C — Workaround Temporary workaround

has been to run on all such retrieved instances, after retrieval, a `model_post_init` function (which doesn't seem to get called by SQLModel). The question is: why does the `model_post_init` not get called when querying through SQLModel? Would it be possible to make it impossible to miss in various usages of the class?

When NOT to use: This fix should not be applied if the model relies on the original behavior of `__pydantic_private__` being None.

Use only if you cannot change versions today. Treat this as a stopgap and remove once upgraded.

Fix reference: https://github.com/pydantic/pydantic/pull/9168

First fixed release: 2.7.1

Last verified: 2026-02-09. Validate in your environment.

When NOT to Use This Fix

This fix should not be applied if the model relies on the original behavior of `__pydantic_private__` being None.

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.1	Fixed

Related Issues

No related fixes found.

Cluster: pydantic:configuration-error Pydantic hub Pydantic best practices All hubs All clusters

Related clusters: Data consistency OpenAPI schema Serialization

Sources

We don’t republish the full GitHub discussion text. Use the links above for context.

Pydantic Revisit cases where `__pydantic_private__` is `None` vs `{}` (Fix)