Azure Cosmos DB Mongo vCore cluster stuck in Failed state, storage keeps growing, delete fails with archive operation error

Hello,

I have an Azure Cosmos DB for MongoDB vCore cluster in East US that appears to be stuck in a failed backend/provider state.

Resource type: Microsoft.DocumentDB/mongoClusters

Cluster: lia-db

Region: eastus

Current ARM state:

• clusterStatus: Failed
• provisioningState: Failed
• Compute tier: M30
• Storage configured: 256 GB
• Public network access: Enabled
• Server version: 8.0

Issue observed:

• Azure Monitor shows StorageUsed increasing continuously.
• On 2026-05-26, StorageUsed reached approximately 226 GB, with StoragePercent around 89%.
• However, MongoDB dbStats across the visible databases shows only about 2.35 GB total size and about 169 MB of actual data.
• Collections do exist, but their sizes do not explain the Azure Monitor storage usage.

I also tried deleting the cluster multiple times. The delete operation is accepted by ARM, but later fails inside the provider.

Delete failure:

{
  "code": "ResourceOperationFailure",
  "message": "The resource operation completed with terminal provisioning state 'Failed'.",
  "details": [
    {
      "code": "UnprocessableEntity",
      "message": "The archive operation failed. An unexpected error occurred while processing the request."
    }
  ]
}

There are no resource locks on the resource group.

The problem seems to be that storage is being consumed at the node/provider level, but this usage is not visible as normal MongoDB collection data. Also, the cluster cannot be deleted because the provider fails during the archive operation.

Questions:

1. Is there a known issue where Azure Cosmos DB for MongoDB vCore storage grows because of internal engine/provider files while MongoDB collections remain small?
2. How can I force-delete or recover a Microsoft.DocumentDB/mongoClusters resource stuck in Failed state?
3. Does this require Microsoft backend cleanup because the delete operation fails during the archive step?

Please advise on the correct recovery or deletion path.