azurerm_site_recovery_replicated_vm forces full replacement of managed_disk on a case-only difference in target_disk_encryption_set_id (regression from #33140, v5.3.0)

[enorlando]

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

AzureRM Provider Version

5.3.0 (regression); confirmed working on 5.2.0

Affected Resource(s)/Data Source(s)

azurerm_site_recovery_replicated_vm

Affected Location(s)

australiasoutheast

Terraform Configuration Files

resource "azurerm_site_recovery_replicated_vm" "xxx-vm1" {
  name                                      = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
  resource_group_name                       = azurerm_resource_group.xxx-asr-rg.name
  recovery_vault_name                       = azurerm_recovery_services_vault.xxx-vault.name
  source_recovery_fabric_name               = azurerm_site_recovery_fabric.primary-fabric.name
  source_vm_id                              = module.xxx-vm1.vm_id
  recovery_replication_policy_id            = azurerm_site_recovery_replication_policy.xxx-retention-policy.id
  source_recovery_protection_container_name = azurerm_site_recovery_protection_container.primary-container.name
  target_resource_group_id                  = azurerm_resource_group.xxx-target-rg.id
  target_recovery_fabric_id                 = azurerm_site_recovery_fabric.recovery-fabric.id
  target_recovery_protection_container_id   = azurerm_site_recovery_protection_container.recovery-container.id
  target_proximity_placement_group_id       = azurerm_proximity_placement_group.xxx-ppg.id

  managed_disk = [
    {
      disk_id                       = "${local.disk_id_prefix}/xxx-vm1-os"
      staging_storage_account_id    = azurerm_storage_account.xxx-staging-storage.id
      target_disk_encryption        = []
      target_disk_encryption_set_id = azurerm_disk_encryption_set.xxx-des.id
      target_disk_type              = var.target-disk-type
      target_replica_disk_type      = var.target-replica-disk-type
      target_resource_group_id      = azurerm_resource_group.xxx-target-rg.id
    },
    {
      disk_id                       = "${local.disk_id_prefix}/xxx-vm1-data"
      staging_storage_account_id    = azurerm_storage_account.xxx-staging-storage.id
      target_disk_encryption        = []
      target_disk_encryption_set_id = azurerm_disk_encryption_set.xxx-des.id
      target_disk_type              = var.target-disk-type
      target_replica_disk_type      = var.target-replica-disk-type
      target_resource_group_id      = azurerm_resource_group.xxx-target-rg.id
    },
  ]

  network_interface {
    source_network_interface_id = module.xxx-vm1.nic_id
    ip_configuration {
      target_subnet_name        = azurerm_subnet.xxx-subnet.name
      failover_test_subnet_name = azurerm_subnet.xxx-subnet.name
    }
  }
}

Debug Output/Panic Output

Isolated terraform plan output — every field matches between state and config except the casing of the resource group segment in target_disk_encryption_set_id:

# azurerm_site_recovery_replicated_vm.xxx-vm1 must be replaced
-/+ resource "azurerm_site_recovery_replicated_vm" "xxx-vm1" {
      ~ managed_disk = [ # forces replacement
          - {
              - target_disk_encryption_set_id = ".../resourceGroups/XXX-KEYVAULT-RG/providers/Microsoft.Compute/diskEncryptionSets/xxx-des"
              - target_disk_type              = "Premium_LRS"
              ... (all other fields identical)
            },
          + {
              + target_disk_encryption_set_id = ".../resourceGroups/xxx-keyvault-rg/providers/Microsoft.Compute/diskEncryptionSets/xxx-des"
              + target_disk_type              = "Premium_LRS"
              ... (all other fields identical)
            },
        ]
    }

Plan: 1 to add, 0 to change, 1 to destroy.

(Two managed_disk entries — OS and data disk — both show the identical pattern.)

Expected Behaviour

Since #33140 (v5.3.0) added update support and a customizeDiff intended to only force-replace when a specific non-updatable attribute changes, unrelated/list-order differences in managed_disk should not force a full block replacement, and genuinely equivalent Azure resource IDs (differing only in segment casing, e.g. resource group name) should not be treated as forcing changes.

Actual Behaviour

Upgrading only the provider version from 5.2.0 → 5.3.0, with no changes to the .tf config, produces a forced replacement of the entire managed_disk list. Reverting to 5.2.0 with the identical config produces a clean/no-op plan.

Separately, attempting to normalise the casing difference by wrapping target_disk_encryption_set_id in lower() causes a hard parse error under 5.3.0:

Error: parsing "...resourcegroups/xxx-keyvault-rg/providers/microsoft.compute/diskencryptionsets/...":
parsing segment "staticResourceGroups": the segment at position 2 didn't match
Expected: .../resourceGroups/.../providers/Microsoft.Compute/diskEncryptionSets/...

Steps to Reproduce

1. Have an existing azurerm_site_recovery_replicated_vm where target_disk_encryption_set_id references a disk encryption set inside a resource group whose actual Azure-stored name casing (e.g. XXX-KEYVAULT-RG) differs from the casing used in the Terraform reference/config (e.g. xxx-keyvault-rg) — created under provider ≤5.2.0, where this was a non-issue.
2. Upgrade the provider to 5.3.0 with no other config changes.
3. Run terraform plan.
4. Observe managed_disk # forces replacement driven solely by the casing difference.

Important Factoids

Reverting to provider 5.2.0 with identical config resolves the forced replacement (clean/no-op plan).

References

#33140 (introduced update support + customizeDiff for managed_disk — source of this regression)
#22075 (fixed this exact class of issue on this exact resource before)
#22101 (fixed this exact class of issue on this exact resource before)

[toddgiguere]

@enorlando I'm having trouble replicating the error. I've deployed a version of this myself, and made sure to use a mixed case resource group for all of my resources, for example: "toddRG-test-2" (I always test with this pattern because it finds issues like this).

I deployed initially with v5.2.0, then upgraded to v5.3.0 and ran a plan, it reports "No changes". I did this in two EU regions but not Australia, I'll replicate with your region tomorrow and try this again.

Our ID we are both using looks very similar: target_disk_encryption_set_id = azurerm_disk_encryption_set.test2.id.

Another difference I noticed is that you have two managed disks, I only have one, I'm going to adjust that tomorrow as well and report back.

[enorlando]

Thanks for testing! Good catch — we're both spanning the same 5.2.0→5.3.0 upgrade with near-identical config, so it's not an authoring difference, and the upgrade alone clearly isn't sufficient (you proved that). My best guess: its more about whether the resource has been through an actual Site Recovery reprotect/failover that re-touched the DES association, ASR's API may echo the casing from whenever that last happened, not the RG's current name. Disk count and region are both still open — keen to see tomorrow's results.

[toddgiguere]

@enorlando I am still unable to reproduce this issue. For each of my tests, I am first deploying my example in v5.2, waiting ~15m, then upgrading to v5.3.0 and running plan, in every scenario I'm getting a response of "No changes".

Some of the configuration elements I have tried, including all of these combined:

• Mixed case resource group name
• Upper case resource group name
• Single managed disk block
• Multiple managed disk blocks
• EU regions
• Australia regions (central and southeast)
• Nested block syntax for managed_disk
• Attribute syntax for managed_disk (your example code above)

In all of those cases I observe no changes reported, after initial 5.2 deployment the state file correctly stores either mixed or upper case IDs correctly, and the Azure API is returning its payload with the mixed or upper case IDs matching the state.

I'm not going to be able to debug this until I can reliably reproduce.

Two notes about your configuration above though:

1. The usage of a string variable instead of resource attribute for disk_id. This is not the ID being flagged above, but it does look different than how we would normally recommend setting an ID field.
   (yours: disk_id = "${local.disk_id_prefix}/xxx-vm1-os")
   (mine: disk_id = azurerm_virtual_machine.test.storage_os_disk[0].managed_disk_id)

2. Setting managed_disk using attribute syntax vs nested block syntax. You are not gaining much from using attribute syntax in this case (managed_disk = [ yourblocks ]), a recommendation would be to use nested block style which is more flexible and allows for optional attributes to be left unset (you would not need the target_disk_encryption = []). Some more info can be read here.

[enorlando]

Thanks for the thorough testing, @toddgiguere
Queried ASR's API directly, bypassing Terraform:

az site-recovery protected-item show --resource-group xxx-asr-rg --fabric-name primary-fabric --protection-container primary-container --name ITEM_ID --vault-name xxx-vault -o json

Live response: "recoveryDiskEncryptionSetId": ".../resourceGroups/XXX-KEYVAULT-RG/.../diskEncryptionSets/xxx-des" — uppercase. But az group show on that RG returns lowercase, its real current name.

We also ruled out our own config as the source: the DES resource references its RG via a proper resource attribute (not hardcoded), and terraform state show confirms the DES's own id is lowercase, matching current config. So the stale casing isn't Terraform state or a config typo — ASR's own control plane is holding a stale-cased ID for this specific replicated item, independent of the RG's actual current name.

All eight of your tested variables (RG casing, disk count, region, block/attribute syntax) are fresh, single-session deploys — ASR writes and reads the casing in one motion, so there's nothing to have drifted. The actual trigger is age/history: whether the item has been through a reprotect/failover, or was originally associated years ago and never re-derived since. That can't be constructed in a single test session, which is why "no changes" is the expected result for all of your tests — not evidence the bug is config-dependent.

• Disk order/count and disk-type changes are unrelated (isolated separately, casing alone still forces replacement).
• Block vs. attribute syntax makes no difference — tested both directly against our resource, identical result.
• Reproduced independently on a second VM in a different subscription, same pattern.
• Reverting to 5.2.0 resolves it (clean plan) in all cases.
• Precedent: azurerm_site_recovery_replicated_vm id case is inconsistent #22075/azurerm_site_recovery_replicated_vm: handle casing issue & update validate func #22101 fixed this same ASR-casing-inconsistency class of bug on other fields of this resource in 2023 — managed_disk's nested fields were never in scope back then since the block was fully ForceNew at the time.

Since the root cause sits in ASR's backend and isn't reproducible via fresh deploy, we think the fix needs to be case-insensitive comparison in managed_disk's customizeDiff for target_disk_encryption_set_id, regardless of how ASR's backend got here. Is there a path to get a maintainer to look at this based on the evidence above?

One more from your earlier notes — the disk_id string interpolation is because our source VM/disks are provisioned via a module that doesn't expose a clean resource attribute here. Worth revisiting on our end, but as you noted, unrelated to this bug.