provider incorrectly reporting name taken for storage accounts that are already a part of terraform configuration and already deployed.

[calebsutton]

Is there an existing issue for this?

• I have searched the existing issues

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 and review the contribution guide to help.

Terraform Version

1.5.2

AzureRM Provider Version

3.83.0

Affected Resource(s)/Data Source(s)

azurerm_storage_account

Terraform Configuration Files

resource "azurerm_storage_account" "example" {
  name                     = "storageaccountname"
  resource_group_name      = azurerm_resource_group.example.name
  location                 = azurerm_resource_group.example.location
  account_tier             = "Standard"
  account_replication_type = "GRS"
}

Debug Output/Panic Output

* `name` is not available: [AlreadyExists] The storage account named storageaccountname is already taken.

Expected Behaviour

Terraform already knew about the storage account and should not have been making any changes to it.

Actual Behaviour

Error about storage account already existing. While true, the storage account already existed in terraform state.
Reverting to AzureRM 3.82.0 allowed a successful plan as expected.

Steps to Reproduce

terraform plan

Important Factoids

No response

References

Issue likely caused by changes in this PR: #23799

[magodo]

@calebsutton Could you please kindly provide a configuration and repro steps so that I can reproduce it locally? I've tested on creating a new storage account with name hardcoded in the config, the apply and then plan works fine for me.

I suspect this is due to your terraform plan result into some change, which includes a change in the name, which in most case shouldn't happen. If there is a change in the name, the check will be done against the new name.

[AlexandreMaldeme]

@magodo We encountered the same issue where the resource group name of the Storage Account would change, which would recreate the SA and trigger this error.
Here's the plan with the azurerm provider version prior to 3.83.0:

  # azurerm_storage_account.prod_account["xxx"] must be replaced
-/+ resource "azurerm_storage_account" "account" {
        ...
        name                              = "xxx"
      ~ resource_group_name               = "oldname" -> "newname" # forces replacement
        ...
}

[calebsutton]

I haven't been able to duplicate the original scenario where there were supposed to be no change to the storage account, but I have been able to duplicate the issue with tainting the storage account.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.