[BUG] data "azurecaf_name" "cdn_frontdoor_origin" causes "Invalid for_each argument" error when using dynamic origin names

[morbendor]

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

Description:

When using the origins input to configure an origin with a dynamic name and private link, the module fails during planning with the following error:

Error: Invalid for_each argument

  on .terraform/modules/cdn_frontdoor/d-naming.tf line 36, in data "azurecaf_name" "cdn_frontdoor_origin":
  36:   for_each = try({ for origin in var.origins : origin.name => origin }, {})
    ├────────────────
    │ var.origins is list of object with 1 element

The "for_each" map includes keys derived from resource attributes that cannot be determined until apply, and so Terraform cannot determine the full set of keys that will identify the instances of this resource.

This issue stems from the following code block in the module:

data "azurecaf_name" "cdn_frontdoor_origin" {
  for_each = try({ for origin in var.origins : origin.name => origin }, {})

  name          = var.stack
  resource_type = "azurerm_cdn_frontdoor_origin"
  prefixes      = var.name_prefix == "" ? null : [local.name_prefix]
  suffixes      = compact([var.client_name, var.environment, local.name_suffix, each.value.name])
  use_slug      = true
  clean_input   = true
  separator     = "-"
}

When an origin's name or any other attribute used in this for_each block depends on a value computed at apply time (such as a resource ID), it causes Terraform to fail because it cannot statically resolve the for_each keys during plan.

Steps to Reproduce:

origins = [
  {
    name                           = "test"
    origin_group_name              = "test"
    certificate_name_check_enabled = true
    private_link = {
      location               = "eastus"
      private_link_target_id = azurerm_private_link_service.front_door_pls.id
    }
    host_name          = "test.com"
    origin_host_header = "test.com"
    weight             = 1000
  },
]

Expected Behavior:

The module should allow dynamic origin configurations using for_each without failing during plan.

Possible Solution:

Consider refactoring the azure_caf logic to have option to disable it for this resource and give static name

Workaround:

Currently, this can only be worked around by using -target to apply resources in two stages, which breaks the declarative workflow.

Additional Context:

Using Terraform v1.5+ with azurerm provider v3.0+.

OpenTofu Version

1.9.2

AzureRM Provider Version

4.26.0

Affected Resource(s)/Data Source(s)

data "azurecaf_name" "cdn_frontdoor_origin"

OpenTofu Configuration Files

origins = [
  {
    name                           = "test"
    origin_group_name              = "test"
    certificate_name_check_enabled = true
    private_link = {
      location               = "eastus"
      private_link_target_id = azurerm_private_link_service.front_door_pls.id
    }
    host_name          = "test.com"
    origin_host_header = "test.com"
    weight             = 1000
  },
]

Debug Output/Panic Output

Error: Invalid for_each argument

  on .terraform/modules/cdn_frontdoor/d-naming.tf line 36, in data "azurecaf_name" "cdn_frontdoor_origin":
  36:   for_each = try({ for origin in var.origins : origin.name => origin }, {})
    ├────────────────
    │ var.origins is list of object with 1 element

The "for_each" map includes keys derived from resource attributes that cannot be determined until apply, and so Terraform cannot determine the full set of keys that will identify the instances of this resource.

Expected Behaviour

Expected Behavior:

The module should allow dynamic origin configurations using for_each without failing during plan.

Possible Solution:

Consider refactoring the for_each logic to avoid relying on values that cannot be determined until apply, or isolate name generation in a way that doesn’t require values from the origin object that depend on runtime information.

Workaround:

Currently, this can only be worked around by using -target to apply resources in two stages, which breaks the declarative workflow.

Additional Context:

Using Terraform v1.5+ with azurerm provider v3.0+.

Actual Behaviour

No response

Steps to Reproduce

No response

Important Factoids

No response

References

No response