Cosmos provider v7.0.14 and v8.0.0 breaks previous OwnsMany behaviour

[markphillips100]

I've encountered an issue whilst upgrading to v8.0.0 so have reproduced the issue in a demo repo to help explain.

https://github.com/markphillips100/efcore-cosmos-sample
The repo has 3 branches:
dotnet7-working
dotnet7
dotnet8

Each of the branches are identical aside from changes to the targetframework and efcore runtime version package references.

The issue is that prior to v7.0.14 the cosmos provider would persist and query an owned (nested) collection property where the actual data persisted did not include a foreign key for the parent. Here is an example document showing what a v7.0.13 would persist (if you use the POST api in swagger from the demo):

{
    "Id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
    "Discriminator": "Family",
    "LastName": "string",
    "id": "Family|3fa85f64-5717-4562-b3fc-2c963f66afa6",
    "Children": [
        {
            "FamilyName": "string",
            "FirstName": "string",
            "Gender": "string"
        }
    ],
    "_rid": "aJItALuWGMcMAAAAAAAAAA==",
    "_self": "dbs/aJItAA==/colls/aJItALuWGMc=/docs/aJItALuWGMcMAAAAAAAAAA==/",
    "_etag": "\"00000000-0000-0000-200e-808634f401da\"",
    "_attachments": "attachments/",
    "_ts": 1700964961
}

As can be seen there is no "FamilyId" in the child object in the Children Array. A subsequent GET operation will happily query this data and return a FamilyId as per the model:

[
  {
    "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
    "lastName": "string",
    "children": [
      {
        "familyId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
        "familyName": "string",
        "firstName": "string",
        "gender": "string"
      }
    ]
  }
]

Switch over to either v7.0.14 or v8.0.0 and the behaviour has changed. Now the provider persists the FamilyId. This might not seem like a big deal but it is.

I use AspNet Identity with a custom cosmos store implementation using the EFCore cosmos provider. The expectation is that the store returns all the user's persisted claims as they are configured as OwnsMany. I can then make a change to a claim in this hierarchy and persist the user as a single document.

When the user is not returned from a query with the claims collection included and subsequently saved (like when Identity updates the security timestamp for example) the user ends up in the database with zero claims. They've been emptied because they were not there when originally queried.

This is a critical bug for any existing user data using the OwnsMany mapping. Is there a way to modify the mapping to reintroduce the previous behaviour?

The mapping I use currently can be seen in the demo here.

[markphillips100]

I have a suspicion the change in behaviour is caused by the fix to issue #31664. In my case though I would not want the Parent Id to be in the child as it shouldn't be necessary from a document database point of view.