terraform-provider-azurerm: azurerm_cosmosdb_account fails with documentdb.DatabaseAccountsClient#CheckNameExists: Failure responding to request: StatusCode=500

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave “+1” or “me too” comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureRM Provider) Version

Terraform v0.12.9 azurerm v2.10.0

Affected Resource(s)

  • azurerm_cosmosdb_account

Terraform Configuration Files

resource "random_integer" "ri" {
  min = 10000
  max = 99999
}

resource "azurerm_cosmosdb_account" "this" {
  name                = "${local.location}${local.subscription}xxx"
  location            = "${local.location}"
  resource_group_name = "${local.location}-${local.subscription}-${local.owner}-rg"
  offer_type          = "Standard"
  kind                = "MongoDB"

  enable_automatic_failover = true

  consistency_policy {
    consistency_level       = "BoundedStaleness"
    max_interval_in_seconds = 10
    max_staleness_prefix    = 200
  }

  geo_location {
    location          = var.db_failover_location
    failover_priority = 1
  }

  geo_location {
    prefix            = "${local.location}${local.subscription}xxx-${random_integer.ri.result}-customid"
    location          = "${local.location}"
    failover_priority = 0
  }

  tags = "${module.tag.tags}"

}

Debug Output

Panic Output

Expected Behavior

Provider creates CosmosDB account

Actual Behavior

Provider does not create CosmosDB account and fails with the following message.

Error: Error checking if CosmosDB Account "xxx" already exists (Resource Group "xxx"): documentdb.DatabaseAccountsClient#CheckNameExists: Failure responding to request: StatusCode=500 -- Original Error: autorest/azure: error response cannot be parsed: "" error: EOF

  on cosmosdb.tf line 1, in resource "azurerm_cosmosdb_account" "this":
   1: resource "azurerm_cosmosdb_account" "this" {

Steps to Reproduce

  1. terraform apply

Important Factoids

Running in Azure Westeurope

References

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 33
  • Comments: 17 (1 by maintainers)

Most upvoted comments

We’ve deployed the fix for this and the issue is resolved.

I have raised a Microsoft support request and the Cosmos product team are apparently looking into this as a possible Azure side issue.

Same issue in Central US and West US

Error checking if CosmosDB Account “<cosmos DB name>” already exists documentdb.DatabaseAccountsClient#CheckNameExists: Failure responding to request: StatusCode=500

This started happening for me today. Started with a completely clean slate using the examples pulled from the documentation. This was in North Europe. I tried deploying to UK South to see if it was a region thing but seems to fail regardless.

Terraform:

resource "azurerm_cosmosdb_account" "db" {
  name = "my-cmdb-resource-name"
  location = "North Europe"
  resource_group_name = azurerm_resource_group.main.name
  offer_type = "Standard"
  kind = "GlobalDocumentDB"
  tags = local.tags

  consistency_policy {
    consistency_level = "Session"
  }

  geo_location {
    location = "North Europe"
    failover_priority = 0
  }
}

Terraform version: 0.12.26 AzureRM: 2.11.0

This has been released in version 2.13.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example:

provider "azurerm" {
    version = "~> 2.13.0"
}
# ... other configuration ...

We have identified the root cause for this and are actively working on a hot fix to the issue. ETA should be tomorrow.

Thanks.

Upstream issue raised: https://github.com/Azure/azure-sdk-for-go/issues/9891 We’ll prepare a similar workaround for the 500 status.

FYI. I’ve been able to get the CosmosDB account by downgrading to azurerm v1.31.0 (which ignores the 500 error). It’s not a pretty workaround but it works for the time being.