[BUG] Model fails to serialize when BackLink has been fetched

[alexdlukens]

Hello all,

Describe the bug
When a model with a BackLink has been retrieved (with fetch_links=1, nesting_depth=1), calling model_dump or model_dump_json raises a PydanticSerializationError

To Reproduce

from beanie import init_beanie, Document, BackLink, Link
from motor.motor_asyncio import AsyncIOMotorClient
from pydantic import Field

class User(Document):
    name: str
    login: Link["Login"]

class Login(Document):
    username: str
    password: str
    user: BackLink[User] = Field(json_schema_extra={"original_field": "login"})
    
User.model_rebuild()

client = AsyncIOMotorClient("mongodb://localhost:27017")
db = client.get_database("test_db")


await init_beanie(
    db,
    document_models=[User, Login],
)

login = Login(username="alice123", password="securepassword")
await login.save()
user1 = User(name="Alice", login=login)
await user1.save()

login_doc = await Login.get(login.id, fetch_links=True, nesting_depth=1)
login_doc.model_dump_json() # error is raised here

Expected behavior

No exception should be thrown. Serialization should succeed, with or without the backlinked data

Additional context

This was the issue I attempted to solve in #1171, but my resolution was not approved. Just looking for any solution to fix the serialization issue

[alexdlukens]

here is the traceback:

---------------------------------------------------------------------------
PydanticSerializationError                Traceback (most recent call last)
Cell In[1], line 31
     28 await user1.save()
     30 login_doc = await Login.get(login.id, fetch_links=True, nesting_depth=1)
---> 31 login_doc.model_dump_json() # error is raised here

File .venv/lib/python3.12/site-packages/pydantic/main.py:519, in BaseModel.model_dump_json(self, indent, include, exclude, context, by_alias, exclude_unset, exclude_defaults, exclude_none, round_trip, warnings, fallback, serialize_as_any)
    479 def model_dump_json(
    480     self,
    481     *,
   (...)    493     serialize_as_any: bool = False,
    494 ) -> str:
    495     """!!! abstract "Usage Documentation"
    496         [`model_dump_json`](../concepts/serialization.md#modelmodel_dump_json)
    497 
   (...)    517         A JSON string representation of the model.
    518     """
--> 519     return self.__pydantic_serializer__.to_json(
    520         self,
    521         indent=indent,
    522         include=include,
    523         exclude=exclude,
    524         context=context,
    525         by_alias=by_alias,
    526         exclude_unset=exclude_unset,
    527         exclude_defaults=exclude_defaults,
    528         exclude_none=exclude_none,
    529         round_trip=round_trip,
    530         warnings=warnings,
    531         fallback=fallback,
    532         serialize_as_any=serialize_as_any,
    533     ).decode()

PydanticSerializationError: Error serializing to JSON: PydanticSerializationError: Error calling function `<lambda>`: AttributeError: 'User' object has no attribute 'document_class'

[js-d-coder]

I am getting this error with Beanie version 1.30.0 and Pydantic version 2.9.1. I am using Pydantic to define schema, validation with fastAPI.

[js-d-coder]

Any ideas how do I fix such an error: Unable to serialize unknown type: <class 'beanie.odm.fields.PydanticObjectId'>

[alexdlukens]

Hi @staticxterm, could you check this out when you get a chance? Pinging you as you initially reviewed the related PR.

I am willing to implement a fix, but not sure what the expected returned data should be
Thanks

[staticxterm]

Hi @alexdlukens,
I am also not sure what the expected returned data should be. BackLink's should not be serializable as they are virtual fields, and their usage is more like a helper to access the "parent" linked document.
I guess they could be added (to be in the serialized output) if they are fetched or somehow exist when the model is initially populated. But even then, I don't know what the real benefit is.
If it breaks serialization or usage with FastAPI (even though it was never recommended to use it that way), okay, I guess we could consider that and fix it, but we need to be careful not to run into that endless fetch issue.

[nbowisdar]

[github-actions]

This issue is stale because it has been open 30 days with no activity.

[github-actions]

This issue is stale because it has been open 30 days with no activity.