the 'working' workarounds were tested by calling Person.model_validate_doc({...}) as per the stack trace

I have another field on the parent Person model like:

    subscriptions: Optional[list[Subscription]] = Field(default_factory=list)

and

class Subscription(EmbeddedModel):
    company_id: Optional[str] = Field(None, key_name="companyId")

...it doesn't seem to have the same problem

So maybe the key_name="companyRelation" on the parent field is also part of the issue

No... if I remove the key_name from parent field and amend the input data to already have company_relations key name then I still get the error

the difference above is that Subscription.company_id is Optional with None default so it can't complain about (falsely) missing value

shouldn't there by some stuff with alias in the generated Pydantic model fields?

https://docs.pydantic.dev/latest/concepts/alias/

I can see that Odmantic also doesn't respect the key_name of fields in EmbeddedModel when they are saved to MongoDB... but only when the field is Optional[list[CompanyRelation]], list[CompanyRelation] works fine

this explains why my application unit tests didn't catch the issue above before we deployed the change - the tests generate test data via the Odmantic model so it was creating records that it could read

Why did the people supporting odmantic make changes to the model configuration. It was perfect when it was flexible. Years of working with models and MongoDB collection/document. Then Type Error replaces working model. No existing documentation just failure. To be honest I thought the schema key/value pair followed by another class statement with Config: collection = 'mycollection' was simple and flexible. Now it seems I have to add a 'model_config and add another JSON structure to reference my collection and that throws another error on a field with key not found but I can see it in the object returned. Yes BSON based on JSON is a key/value pair structure. But this is obscuring terms and not needed. We have ObjectID but many of use don't use it. I do most of my queries on fields. Simply listed as key/value pairs for a model which is data that I choose to use. The whole idea of a repository tool is the flexibility to map to data and validate in the code. Not have the repository tool set outside requirements in mapping to a database table/collection or document. No we have to rewrite the code base and that is a problem. New ideas about conforming to some standard that breaks 100,000 lines of code is not the way. Set the new standards but don't break the code.