CosmosDB Account API should accept the defaultIdentity property while restoring CosmosDB Account

[neil-yechenwei]

Hi team,

Since 12/12/2022, we found CosmosDB Account API doesn't accept the defaultIdentity property anymore and API failed with below error message while restoring CosmosDB Account. But previously it works fine to restore CosmosDB Account with defaultIdentity. Seems it's a breaking change at service side. Could you take a look this blocking issue? Thanks.

The request payload to restore CosmosDB Account with the defaultIdentity property:

PUT https://management.azure.com/subscriptions/xx-xx-xx-xx/resourceGroups/acctestRG-cosmos-test444/providers/Microsoft.DocumentDB/databaseAccounts/acctest-carestore-test444?api-version=2022-05-15

{
    "location": "westeurope",
    "kind": "GlobalDocumentDB",
    "tags": {},
    "properties": {
        "defaultIdentity": "FirstPartyIdentity",
        "locations": [
            {
                "locationName": "West Europe",
                "failoverPriority": 0
            }
        ],
        "databaseAccountOfferType": "Standard",
        "createMode": "Restore",
        "restoreParameters": {
            "restoreMode": "PointInTime",
            "restoreSource": "/subscriptions/xx-xx-xx-xx/providers/Microsoft.DocumentDB/locations/westeurope/restorableDatabaseAccounts/xx-xx-xx-xx",
            "restoreTimestampInUtc": "2022-12-28T08:25:18.000Z",
            "databasesToRestore": [
                {
                    "databaseName": "acctest-sqldb-test444",
                    "collectionNames": [
                        "acctest-CSQLC-test444"
                    ]
                }
            ]
        }
    }
}

The error message:

{
  "code": "BadRequest",
  "message": "Invalid restore request. Need to provide a User-Assigned identity as DefaultIdentity along with Managed Identity Info\r\nActivityId: xx-xx-xx-xx, Microsoft.Azure.Documents.Common/2.14.0"
}

Note: Based on above investigation result, I also tried to restore “CosmosDB Account” without the “defaultIdentity” property, API succeeded to restore CosmosDB Account. And then I invoked “CosmosDB Account GET” API to retrieve this restored CosmosDB Account, I found the value of the “defaultIdentity” property is "FirstPartyIdentity". So, per my understanding, to align with previous API behavior, I assume service API should allow to set “defaultIdentity” in request payload while restoring because it’s always set at service side even if it isn’t set in request payload.

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @pjohari-ms, @MehaKaushik, @zfoster, @kushagraThapar, @simorenoh, @simplynaveen20, @abinav2307.

Issue Details

---

Hi team, Since 12/12/2022, we found CosmosDB Account API doesn't accept the defaultIdentity property anymore and API failed with below error message while restoring CosmosDB Account. But previously it works fine to restore CosmosDB Account with defaultIdentity. Seems it's a breaking change at service side. Could you take a look this blocking issue? Thanks. The request payload to restore CosmosDB Account with the defaultIdentity property: ``` PUT https://management.azure.com/subscriptions/xx-xx-xx-xx/resourceGroups/acctestRG-cosmos-test444/providers/Microsoft.DocumentDB/databaseAccounts/acctest-carestore-test444?api-version=2022-05-15 { "location": "westeurope", "kind": "GlobalDocumentDB", "tags": {}, "properties": { "defaultIdentity": "FirstPartyIdentity", "locations": [ { "locationName": "West Europe", "failoverPriority": 0 } ], "databaseAccountOfferType": "Standard", "createMode": "Restore", "restoreParameters": { "restoreMode": "PointInTime", "restoreSource": "/subscriptions/xx-xx-xx-xx/providers/Microsoft.DocumentDB/locations/westeurope/restorableDatabaseAccounts/xx-xx-xx-xx", "restoreTimestampInUtc": "2022-12-28T08:25:18.000Z", "databasesToRestore": [ { "databaseName": "acctest-sqldb-test444", "collectionNames": [ "acctest-CSQLC-test444" ] } ] } } } ``` The error message: ``` { "code": "BadRequest", "message": "Invalid restore request. Need to provide a User-Assigned identity as DefaultIdentity along with Managed Identity Info\r\nActivityId: xx-xx-xx-xx, Microsoft.Azure.Documents.Common/2.14.0" } ``` Note: Based on above investigation result, I also tried to restore “CosmosDB Account” without the “defaultIdentity” property, API succeeded to restore CosmosDB Account. Then I invoked “[CosmosDB Account GET](https://learn.microsoft.com/en-us/rest/api/cosmos-db-resource-provider/2022-05-15/database-accounts/get?tabs=HTTP)” API to retrieve this restored CosmosDB Account, I found the value of the “defaultIdentity” property is "FirstPartyIdentity". Hence, to align with previous API behavior/avoid this regression issue, I assume service API may need to allow to set “defaultIdentity” in request payload while restoring because it’s always set at service side even if it isn’t set in request payload.

Author:	neil-yechenwei
Assignees:	-
Labels:	`Cosmos`, `Service Attention`, `needs-triage`
Milestone:	-

[levgoronshteyn]

@pjohari-ms, @MehaKaushik, @zfoster, @kushagraThapar, @simorenoh, @simplynaveen20, @abinav2307

Any update on this? I have another client experiencing the same issue.

[TheovanKraay]

Hello @neil-yechenwei. Can you please raise a support case for this, and request it to be assigned to the backup and restore team in Cosmos DB. It needs to be investigated by that team.

@levgoronshteyn - we don't control this from the Cosmos DB SDK for data plane operations (this is management SDK, and I am not sure it can be controlled there either, but either way, it needs to be investigated by the above team).

[levgoronshteyn]

@neil-yechenwei could you please update us if the case has been opened with the backup and restore team in Cosmos DB?

[neil-yechenwei]

After investigated, I found service API's behavior is changed and now it doesn't allow the default_identity_type(defaultIdentity) in restore request (create_mode = Restore).

@vinhms from service team(cosmosdb) confirmed there is no "default value" for defaultIdentity in restore request. While for provisioning request, a source account will have FirstPartyIdentity if defaultIdentity is not provided, but this is not true for restore request. The defaultIdentity provided in the restore request is ignored and it will always inherit the defaultIdentity from the source account. They will update the documentation to reflect this. As such, there should not be a default value since the empty value for defaultIdentity has the special meaning to service API.

vinhms is working on the fix that doesn't validate the defaultIdentity in restore request at service side.

As vinhms suggested, the defaultIdentity for target account is inherited from the source account and there is no default defaultIdentity. So I also submitted a PR to remove the default value for defaultIdentity.