State migration to 4.0 fails to unmarshall azurerm_cosmosdb_account.ip_range_filter field

[AndreiBarbuOz]

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

1.9.5

AzureRM Provider Version

4.0.1

Affected Resource(s)/Data Source(s)

azurerm_cosmosdb_account

Terraform Configuration Files

resource "azurerm_cosmosdb_account" "hello_world" {
  name                = var.cosmosdb_account_name
  location            = var.location
  resource_group_name = var.resource_group_name
  offer_type          = "Standard"
  kind                = "GlobalDocumentDB"
  capabilities {
    name = "EnableServerless"
  }

  consistency_policy {
    consistency_level = "Session"
  }

  geo_location {
    location          = var.location
    failover_priority = 0
  }

  public_network_access_enabled = true
  ip_range_filter               = "0.0.0.0"
}

followed by an upgrade of the provider

### Debug Output/Panic Output

```shell
N/A

Expected Behaviour

Expected the field to be successfully migrated

Actual Behaviour

│ Error: missing expected [
│
│
╵
╷
│ Error: missing expected [
│
│   with azurerm_cosmosdb_account.hello_world,
│   on main.tf line 318, in resource "azurerm_cosmosdb_account" "hello_world":
│  318: resource "azurerm_cosmosdb_account" "hello_world" {

Steps to Reproduce

No response

Important Factoids

No response

References

No response

[oraum]

I'm seeing a somewhat similar error when trying to migrate from 3.116.0 to 4.0.1:

Error decoding "azurerm_cosmosdb_account.hello_world" from prior state:
unsupported attribute "connection_strings"

Error: missing expected [
...

As the connection_strings property was dropped according to changelog - I would expect the provider to migrate/drop the field automatically from state or otherwise a note in changelog on how to remove the property manually

[stephybun]

@oraum the Error decoding message you're seeing there is misleading, the issue is that the state isn't able to read the ip_range_filter property which is still in a string format.

The underlying type for the field ip_range_filter changed from a string to a set in v4.0, which means the resource needs to be removed from state, the ip_range_filter argument updated to a set, then the resource can be imported.

[oraum]

@stephybun thanks for the notice, removing the cosmos db from state and re-importing it did indeed solve the issue for me.

[achistef]

+1.
We're facing the missing expected [ and unsupported attribute "connection_strings" errors when migrating our IAC to v4.
Will there be a solution that does not involve re-importing everything to the state?

[pacorreia]

Same happens due to the partition_key_path.

Also when I do a dump from the state file using version 4.x.x, no cosmosdb entries there, 0, nothing, gone... I just get warnings on failing to decode CosmosDb resource properties because of presence of an unknown one.

Before version 4.x.x, there were a couple of deprecated properties that I've removed and started using the one's, but seems the state file was not properly "cleaned" up and now we've garbage conflicting with the new version that no longer recognizes.

[dimiter-todorov-georgiev]

I am facing a similar issue, upgrading from azurerm 3.116.0 to 4.0.1. The connection_strings property cannot be imported from the previous state, and I get a cryptic "missing [" error. I don't have ip_filter_range in my configs. I've been able to stabilize the situation by rolling back to 3.116.0. Waiting for this issue to be resolved before I attempt another upgrade.

[Benj13]

I tried the removing and re-importing the resource from the state and that did the trick. Not ideal but at least I was able to deploy using 4.0.1

[pacorreia]

I tried the removing and re-importing the resource from the state and that did the trick. Not ideal but at least I was able to deploy using 4.0.1

yep that does the trick as it will effective remove all entres, but not the desired solution, but does help further testing the new version

[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.