Parsing Error in "azurerm_media_services_account" with azurerm 3.34.0

[Sanorikos]

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

Terraform Version

1.3.6

AzureRM Provider Version

3.34.0

Affected Resource(s)/Data Source(s)

azurerm_media_services_account

Terraform Configuration Files

resource "azurerm_media_services_account" "account" {
  lifecycle {
    ignore_changes = [storage_authentication_type]
  }
  location            = var.region
  name                = "${var.customer}${var.project}${var.environment}mediaacc${var.name_suffix}"
  resource_group_name = var.resource_group_name

  dynamic "storage_account" {
    for_each = var.storage_accounts
    content {
      id         = storage_account.value.id
      is_primary = storage_account.value.is_primary

    }
  }
  storage_authentication_type = var.storage_authentication_type

}

Debug Output/Panic Output

Resource-ID from Portal: /subscriptions/xxxxxxx/resourceGroups/xxxx-media/providers/Microsoft.Media/mediaservices/xxxxmediaaccmain

╷
│ Error: parsing "/subscriptions/xxxxxxxx/resourceGroups/xxxxx-media/providers/Microsoft.Media/mediaservices/xxxxxmediaaccmain": parsing segment "staticMediaServices": expected the segment "mediaservices" to be "mediaServices"
│
│   with module.mediaServicesAccount.azurerm_media_services_account.account,
│   on .terraform/modules/mediaServicesAccount/main.tf line 1, in resource "azurerm_media_services_account" "account":
│    1: resource "azurerm_media_services_account" "account" {
│
╵

Expected Behaviour

With azurerm 3.33.0

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are
needed.

Actual Behaviour

With azurerm 3.34.0
╷
│ Error: parsing "/subscriptions/xxxxxx/resourceGroups/xxxx-media/providers/Microsoft.Media/mediaservices/xxxxmediaaccmain": parsing segment "staticMediaServices": expected the segment "mediaservices" to be "mediaServices"
│
│ with module.mediaServicesAccount.azurerm_media_services_account.account,
│ on .terraform/modules/mediaServicesAccount/main.tf line 1, in resource "azurerm_media_services_account" "account":
│ 1: resource "azurerm_media_services_account" "account" {
│
╵

Steps to Reproduce

1. terraform init
2. terraform plan

Important Factoids

No response

References

No response

[tombuildsstuff]

hi @Sanorikos

Thanks for opening this issue.

As mentioned in the error message here:

expected the segment "mediaservices" to be "mediaServices"

.. Terraform's expecting the Resource ID to match a given format but a different casing is being specified, taking a looking through here the Resource ID being specified:

/subscriptions/xxxxxx/resourceGroups/xxxx-media/providers/Microsoft.Media/mediaservices/xxxxmediaaccmain

versus the Resource ID we're expecting the format:

/subscriptions/xxxxxx/resourceGroups/xxxx-media/providers/Microsoft.Media/mediaServices/xxxxmediaaccmain

Unfortunately taking a look through here it appears that the import documentation is out of sync here, as such I've opened #19557 to get that updated - however it should be possible to fix this by updating the casing on the Resource ID value being specified (that is mediaservices -> mediaServices).

The behaviour of the Azure API is inconsistent insofar as Resource IDs are supposed to be case-insensitive during Requests and case-sensitive during Responses. Unfortunately, a number of API's don't behave in this manner and silently fail (in really subtle ways) when the casing doesn't match what the API is expecting. As such we're ultimately moving towards validating Resource IDs match the casing that's expected, which'll allow us (in the medium-term) to workaround these API/casing issues. However (as in this case) some user input may need updating to ensure the casing matches.

Whilst that's unfortunate that's affected you in this case, as mentioned above it should be possible to workaround this by updating the casing here, which'll allow terraform plan to succeed - would you be able to take a look?

Since this should be fixed by updating the casing being used here, I'm going to close this issue for the moment however please let us know if that doesn't work for you and we'll take another look.

Thanks!

[lra]

We have the same issue, and we had to search and replace all instances of:

/providers/Microsoft.Media/mediaservices/ -> /providers/Microsoft.Media/mediaServices/
/providers/microsoft.storage/storageAccounts/ -> /providers/Microsoft.Storage/storageAccounts/

in our all states.

I'm writing this here because I'm sure others will encounter the same issues due to Azure's inconcistent naming convention.

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