panic: interface conversion: interface {} is []interface {}, not string in version 4.1.0

[mpigram1]

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 comments along the lines of "+1", "me too" or "any updates", 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

Terraform v1.9.5 on linux_amd64

AzureRM Provider Version

provider registry.terraform.io/hashicorp/azurerm v4.1.0

Affected Resource(s)/Data Source(s)

azurerm_cosmosdb_account

Terraform Configuration Files

resource "azurerm_cosmosdb_account" "cosmosdb" {
  name                              = format("cosmos-%s-%s", var.service_name, var.env)
  location                          = var.location
  resource_group_name               = var.resource_group_name
  offer_type                        = "Standard"
  kind                              = "GlobalDocumentDB"
  is_virtual_network_filter_enabled = true

  dynamic "virtual_network_rule" {
    for_each = var.vnet_subnet_id

    content {
      id = virtual_network_rule.value.id
    }
  }

  analytical_storage {
    schema_type = var.analytical_storage
  }
  backup {
    type = var.backup
  }
  capacity {
    total_throughput_limit = var.capacity
  }

  dynamic "consistency_policy" {
    for_each = var.consistency_policy

    content {
      consistency_level       = consistency_policy.value.consistency_level
      max_interval_in_seconds = consistency_policy.value.max_interval_in_seconds
      max_staleness_prefix    = consistency_policy.value.max_staleness_prefix
    }
  }

  dynamic "geo_location" {
    for_each = var.geo_location

    content {
      location          = geo_location.value.location
      failover_priority = geo_location.value.failover_priority
      zone_redundant    = geo_location.value.zone_redundant
    }
  }
}

variable "location" {
  description = "Azure region to use."
  type        = string
}

variable "vnet_subnet_id" {
  description = "ID of the virtual network subnet."
  type = list(object({
    id = string
  }))
}

variable "resource_group_name" {
  type        = string
  description = "Default resource group name that the database will be created in."
}

variable "env" {
  description = "Environment name."
  type        = string
}

variable "service_name" {
  description = "Name of the service."
  type        = string
}

variable "subscription_id" {
  description = "Subscription ID"
  type        = string
}

variable "analytical_storage" {
  description = "Enable analytical storage for this Cosmos DB"
  type        = string
}

variable "backup" {
  description = "Type of backup"
  type        = string
}

variable "capacity" {
  description = "The total throughput limit imposed on this Cosmos DB account (RU/s)"
  type        = number
}

variable "consistency_policy" {
  description = "Consistency policies"
  type = list(object({
    consistency_level       = string
    max_interval_in_seconds = number
    max_staleness_prefix    = number
  }))
}

variable "geo_location" {
  description = "Configures the geographic locations the data is replicated to"
  type = list(object({
    location          = string
    failover_priority = number
    zone_redundant    = bool
  }))
}

### Debug Output/Panic Output

```shell
Planning failed. Terraform encountered an error while generating this plan.

╷
│ Error: Request cancelled
│ 
│   with module.container_apps.azurerm_container_app_environment.container_env,
│   on ../../modules/container-apps/main.tf line 1, in resource "azurerm_container_app_environment" "container_env":
│    1: resource "azurerm_container_app_environment" "container_env" {
│ 
│ The plugin.(*GRPCProvider).ReadResource request was cancelled.
╵
╷
│ Error: Plugin did not respond
│ 
│   with module.cosmos_db.azurerm_cosmosdb_account.cosmosdb,
│   on ../../modules/cosmos-db/main.tf line 1, in resource "azurerm_cosmosdb_account" "cosmosdb":
│    1: resource "azurerm_cosmosdb_account" "cosmosdb" {
│ 
│ The plugin encountered an error, and failed to respond to the plugin.(*GRPCProvider).UpgradeResourceState call. The plugin logs may contain more details.
╵
╷
│ Error: Plugin did not respond
│ 
│   with module.key_vault.azurerm_key_vault.key_vault,
│   on ../../modules/key-vault/main.tf line 3, in resource "azurerm_key_vault" "key_vault":
│    3: resource "azurerm_key_vault" "key_vault" {
│ 
│ The plugin encountered an error, and failed to respond to the plugin.(*GRPCProvider).ReadResource call. The plugin logs may contain more details.
╵
╷
│ Error: Plugin did not respond
│ 
│   with module.managed_identities_accounting_function.azurerm_role_assignment.role_assignment["/providers/Microsoft.Authorization/roleDefinitions/7f951dda-4ed3-4680-a7ca-43fe172d538d"],
│   on ../../modules/managed-identities/main.tf line 7, in resource "azurerm_role_assignment" "role_assignment":
│    7: resource "azurerm_role_assignment" "role_assignment" {
│ 
│ The plugin encountered an error, and failed to respond to the plugin.(*GRPCProvider).ReadResource call. The plugin logs may contain more details.
╵
╷
│ Error: Plugin did not respond
│ 
│   with module.managed_identities_accounting_service.azurerm_role_assignment.role_assignment["/providers/Microsoft.Authorization/roleDefinitions/7f951dda-4ed3-4680-a7ca-43fe172d538d"],
│   on ../../modules/managed-identities/main.tf line 7, in resource "azurerm_role_assignment" "role_assignment":
│    7: resource "azurerm_role_assignment" "role_assignment" {
│ 
│ The plugin encountered an error, and failed to respond to the plugin.(*GRPCProvider).ReadResource call. The plugin logs may contain more details.
╵
╷
│ Error: Plugin did not respond
│ 
│   with module.managed_identities_accounting_grpc.azurerm_role_assignment.role_assignment["/providers/Microsoft.Authorization/roleDefinitions/7f951dda-4ed3-4680-a7ca-43fe172d538d"],
│   on ../../modules/managed-identities/main.tf line 7, in resource "azurerm_role_assignment" "role_assignment":
│    7: resource "azurerm_role_assignment" "role_assignment" {
│ 
│ The plugin encountered an error, and failed to respond to the plugin.(*GRPCProvider).ReadResource call. The plugin logs may contain more details.
╵
╷
│ Error: Plugin did not respond
│ 
│   with module.storage_account_accounting_function.azurerm_storage_account.storage_account,
│   on ../../modules/storage-account/main.tf line 3, in resource "azurerm_storage_account" "storage_account":
│    3: resource "azurerm_storage_account" "storage_account" {
│ 
│ The plugin encountered an error, and failed to respond to the plugin.(*GRPCProvider).ReadResource call. The plugin logs may contain more details.
╵
╷
│ Error: Plugin did not respond
│ 
│   with module.windows-vm-test.azurerm_network_interface.nic,
│   on ../../modules/windows-vm-test/main.tf line 1, in resource "azurerm_network_interface" "nic":
│    1: resource "azurerm_network_interface" "nic" {
│ 
│ The plugin encountered an error, and failed to respond to the plugin.(*GRPCProvider).ReadResource call. The plugin logs may contain more details.
╵

Stack trace from the terraform-provider-azurerm_v4.1.0_x5 plugin:

panic: interface conversion: interface {} is []interface {}, not string

goroutine 605 [running]:
github.com/hashicorp/terraform-provider-azurerm/internal/services/cosmos/migration.(*CosmosDBAccountV0toV1).UpgradeFunc.CosmosDBAccountV0toV1.UpgradeFunc.func1({0x0?, 0x0?}, 0x0?, {0x0?, 0x0?})
        github.com/hashicorp/terraform-provider-azurerm/internal/services/cosmos/migration/cosmosdb_account.go:560 +0xf0
github.com/hashicorp/terraform-provider-azurerm/internal/tf/pluginsdk.StateUpgrades.func1({0x8b0c578, 0xc0018d9ec0}, 0x0?, {0x729e040, 0xc0013da900})
        github.com/hashicorp/terraform-provider-azurerm/internal/tf/pluginsdk/state_upgrades.go:55 +0x5e
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).upgradeJSONState(0xc0009dcf18, {0x8b0c578, 0xc0018d9ec0}, 0xd?, 0x832002a?, 0x14?)
        github.com/hashicorp/terraform-plugin-sdk/v2@v2.33.0/helper/schema/grpc_provider.go:491 +0x75
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).UpgradeResourceState(0xc0009dcf18, {0x8b0c578?, 0xc0018d9dd0?}, 0xc003d623c0)
        github.com/hashicorp/terraform-plugin-sdk/v2@v2.33.0/helper/schema/grpc_provider.go:367 +0x3fa
github.com/hashicorp/terraform-plugin-mux/tf5muxserver.(*muxServer).UpgradeResourceState(0x8b0c5b0?, {0x8b0c578?, 0xc0018d9ad0?}, 0xc003d623c0)
        github.com/hashicorp/terraform-plugin-mux@v0.15.0/tf5muxserver/mux_server_UpgradeResourceState.go:36 +0x1a2
github.com/hashicorp/terraform-plugin-go/tfprotov5/tf5server.(*server).UpgradeResourceState(0xc001631d60, {0x8b0c578?, 0xc0018d9380?}, 0xc001faf180)
        github.com/hashicorp/terraform-plugin-go@v0.23.0/tfprotov5/tf5server/server.go:750 +0x27b
github.com/hashicorp/terraform-plugin-go/tfprotov5/internal/tfplugin5._Provider_UpgradeResourceState_Handler({0x7fbde60?, 0xc001631d60}, {0x8b0c578, 0xc0018d9380}, 0xc001936700, 0x0)
        github.com/hashicorp/terraform-plugin-go@v0.23.0/tfprotov5/internal/tfplugin5/tfplugin5_grpc.pb.go:446 +0x16c
google.golang.org/grpc.(*Server).processUnaryRPC(0xc000241000, {0x8b0c578, 0xc0018d92f0}, {0x8b38f60, 0xc000232600}, 0xc001c5f8c0, 0xc0017fb920, 0xe173738, 0x0)
        google.golang.org/grpc@v1.63.2/server.go:1369 +0xe23
google.golang.org/grpc.(*Server).handleStream(0xc000241000, {0x8b38f60, 0xc000232600}, 0xc001c5f8c0)
        google.golang.org/grpc@v1.63.2/server.go:1780 +0x1016
google.golang.org/grpc.(*Server).serveStreams.func2.1()
        google.golang.org/grpc@v1.63.2/server.go:1019 +0x8b
created by google.golang.org/grpc.(*Server).serveStreams.func2 in goroutine 59
        google.golang.org/grpc@v1.63.2/server.go:1030 +0x135

Error: The terraform-provider-azurerm_v4.1.0_x5 plugin crashed!

This is always indicative of a bug within the plugin. It would be immensely
helpful if you could report the crash with the plugin's maintainers so that it
can be fixed. The output above should help diagnose the issue.

### Expected Behaviour

A successful plan 

### Actual Behaviour

Error: The terraform-provider-azurerm_v4.1.0_x5 plugin crashed!

### Steps to Reproduce

terraform plan -var-file=./tfvars/prod.terraform.tfvars

### Important Factoids

_No response_

### References

_No response_

[mpigram1]

I've had to pull my provider version back to 3.112.0 to stop this error from happening.

Not ideal considering I'd made changes that incorporated some new features.

Any help regarding this would be great but for now I'm unblocked.

[orgads]

This happened to me after I applied with 4.0.1, and then tried to apply again with 4.1.0.

Solved by manually editing the state file and changing schema_version of cosmosdb to 1.

[neil-yechenwei]

Thanks for raising this issue. Seems I can't reproduce this issue after the version is upgraded from 3.116.0 to 4.1.0. Please check and ensure if "ip_range_filter" is string type in the state file. If yes, please directly update to 4.1.0 to see if the issue still exists? Thanks.

tf config:

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "test" {
  name     = "acctestRG-cosmos-test06"
  location = "eastus"
}

resource "azurerm_virtual_network" "test" {
  name                = "acctest-VNET-test06"
  resource_group_name = azurerm_resource_group.test.name
  address_space       = ["10.0.0.0/16"]
  location            = azurerm_resource_group.test.location
  dns_servers         = ["10.0.0.4", "10.0.0.5"]
}

resource "azurerm_subnet" "subnet1" {
  name                                          = "acctest-SN1-test06-1"
  resource_group_name                           = azurerm_resource_group.test.name
  virtual_network_name                          = azurerm_virtual_network.test.name
  address_prefixes                              = ["10.0.1.0/24"]
  private_endpoint_network_policies             = "Disabled"
  private_link_service_network_policies_enabled = false
}

resource "azurerm_subnet" "subnet2" {
  name                                          = "acctest-SN2-test06-2"
  resource_group_name                           = azurerm_resource_group.test.name
  virtual_network_name                          = azurerm_virtual_network.test.name
  address_prefixes                              = ["10.0.2.0/24"]
  service_endpoints                             = ["Microsoft.AzureCosmosDB"]
  private_endpoint_network_policies             = "Disabled"
  private_link_service_network_policies_enabled = false
}

resource "azurerm_cosmosdb_account" "test" {
  name                              = "acctest-ca-test06"
  location                          = azurerm_resource_group.test.location
  resource_group_name               = azurerm_resource_group.test.name
  offer_type                        = "Standard"
  kind                              = "GlobalDocumentDB"
  is_virtual_network_filter_enabled = true

  virtual_network_rule {
    id                                   = azurerm_subnet.subnet1.id
    ignore_missing_vnet_service_endpoint = true
  }

  virtual_network_rule {
    id                                   = azurerm_subnet.subnet2.id
    ignore_missing_vnet_service_endpoint = false
  }

  analytical_storage {
    schema_type = "WellDefined"
  }

  backup {
    type = "Continuous"
  }

  capacity {
    total_throughput_limit = 200
  }

  consistency_policy {
    consistency_level       = "Eventual"
    max_interval_in_seconds = 5
    max_staleness_prefix    = 100
  }

  geo_location {
    location          = azurerm_resource_group.test.location
    failover_priority = 0
    zone_redundant    = false
  }
}

Reproduce steps:

Step 1 - Run "tf apply" with above tf config and v3.115.0
Step 2 - Upgrade version to v4.1.0 and run "tf plan"

[tonygambone]

I can reproduce using @neil-yechenwei's config using these steps:

1. Create using 3.116.0
2. Switch to 4.0.1
3. terraform plan now causes this issue, so remove azurerm_cosmosdb_account.test from state and re-import it
4. terraform plan is now successful, ip_range_filter in state has now been changed from "" to []
5. Switch to 4.1.0
6. terraform plan now causes the panic: interface conversion: interface {} is []interface {}, not string error

So it seems to affect configs that first upgraded to 4.0.1 using the remove/import workaround, then upgrade to 4.1.0.

ETA: Removing and re-importing the account under 4.1.0 works, as does going directly from 3.116.0 -> 4.1.0 without first going to 4.0.1.

[tonygambone]

I also get the panic if I create the resources under 4.0.1 and then upgrade to 4.1.0. Removing and re-importing also fixes things in this situation.

[empowerScott]

Getting the same error after remove/import on 4.0.1 and now going to version 4.1.0

[babuga365]

I'm also getting the same error after remove/import cosmos db account on 4.0.1 and now going to version 4.1.0 from version 4.0.1.
Getting this issues only on environment having cosmosdb setup.

[dansali]

v3.115.0 -> v4.0.1 broke ip_range_filter changing from string of ips "10.0.0.1,10.0.0.2" to array with CIDR notation ["10.0.0.1/32", "10.0.0.2/32"]. terraform would reply with: Error: missing expected [ even after updating code with existing cosmosdb resource. Here: #27242

v4.0.1 -> v4.1.0 broke as this provider error in OP.

If you fixed your state file manually by removing that field or reimported the cosmosdb then your schema_version for resource azurerm_cosmosdb_account will be 0. Changing this to 1 has fixed this issue for me. Or you could try reimporting your cosmosdb if possible?

Fixed the bug from earlier and then create a new bug. Lol.
#27276

Note: I didn't reimport my resource, I modified the state file which is not best practice.. So not sure the behaviour of schema_version with an import.

[babuga365]

v3.115.0 -> v4.0.1 broke ip_range_filter changing from string of ips "10.0.0.1,10.0.0.2" to array with CIDR notation ["10.0.0.1/32", "10.0.0.2/32"]. terraform would reply with: Error: missing expected [ even after updating code with existing cosmosdb resource. Here: #27242

v4.0.1 -> v4.1.0 broke as this provider error in OP.

If you fixed your state file manually by removing that field or reimported the cosmosdb then your schema_version for resource azurerm_cosmosdb_account will be 0. Changing this to 1 has fixed this issue for me. Or you could try reimporting your cosmosdb if possible?

Fixed the bug from earlier and then create a new bug. Lol. #27276

Note: I didn't reimport my resource, I modified the state file which is not best practice.. So not sure the behaviour of schema_version with an import.

@dansali, I don't want to change the state files by own. I have many cosmos db accounts and remove/reimport took me 2 days to complete it as a workaround for the previous version. now again doing the same for this version will cause any issue in next version. Better I will wait for fixing this issue fully in next release will help me with small work.

I could see you merged some code and do we need to remove and reimport resource from tfstate file for cosmosdb account? or can we wait for next release to fix this issue fully?

[dansali]

Better I will wait for fixing this issue fully in next release will help me with small work.

You could enforce your azurerm provider to v4.0.1 to bypass this issue until it's hopefully fixed in a future release.

@babuga365 I think that could work

[dansali]

@babuga365 I recommended a fix for this one for the developer who wrote this. I didn't merge anything, just went through same issue migrating from v4.0.1 to v4.1.0

#27276 (comment)

[carnei-ro]

@orgads thanks for the workaround, it worked here!

[babuga365]

Better I will wait for fixing this issue fully in next release will help me with small work.

You could enforce your azurerm provider to v4.0.1 to bypass this issue until it's hopefully fixed in a future release.

@babuga365 I think that could work

@dansali , I have already migrated from v3.116.0 to v4.0.1
I will wait for one more release with final fix. I don't want to keep on doing same remove/re-import resource in state file as workarounds

[teowa]

There is a fix for the panic during migration from 4.0.1 to 4.1.0 in #27302, which will release in 4.2.0. Directly migration from 3.x to 4.1.0 should have no issue.
If you met the panic issue during migration from 4.0.1 to 4.1.0. You can workaround the issue by terraform state rm followed by terraform import the azurerm_cosmosdb_account resources.
thanks.