I would argue this is not a bug in pydantic but a misuse of a performance-oriented validation escape hatch. You should only use model_construct if you are confident that you are creating the model in a valid way, as the whole point is to elide validation for the sake of performance. If you have bugs in your application code caused by that, I would advise against the use of model_construct. Also, the main reason to use model_construct is for performance, and given the massive performance improvements in pydantic v2, it may be worth benchmarking whether there are even any noticeable performance benefits to the use of model_construct anyway. In at least some cases (especially for shallow/simple models), model_construct can be comparable or worse in performance than model_validate anyway.

The reason this would have worked in earlier versions of FastAPI/pydantic was the use of the "secure cloned field", whose purpose was to prevent extra fields from being included at serialization time. But this came at the price of a massive performance overhead caused by revalidating data that in principle was already known to be valid.

We made specific changes in pydantic v2 to render the secure cloned field unnecessary, in particular, serializing models based on their schema rather than through recursive calls to the field attributes' dump methods, and accepting subclass instances as allowed for fields without revalidation, and this is responsible for significant performance improvements in versions of FastAPI using pydantic v2.

As a consequence, there are now issues with invalidly-constructed models not being validated properly, but again, I would consider this a misuse of model_construct rather than a bug in pydantic/fastapi.

Amazing writeup as always @dmontagu, thanks! And thanks @marielejeune, I think that would probably answer it, if you have more questions/problems, please create a new discussion question. 🤓