The try function causes (known when applied) for values that can be predicted

[msl0]

Terraform Version

Terraform v1.4.4
on windows_amd64

Terraform Configuration Files

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "this" {
  for_each = local.apps
  name     = each.value.name
  location = try(each.value.location, "westeurope")
  lifecycle {
    ignore_changes = [tags]
  }
}


resource "azurerm_availability_set" "this" {
  for_each            = local.apps
  name                = each.value.name
  location            = try(azurerm_resource_group.this[each.key].location, "westeurope")
  resource_group_name = azurerm_resource_group.this[each.key].name
  lifecycle {
    ignore_changes = [tags]
  }
}

locals {
  apps = {
    test = {
      name     = "test"
      location = "westeurope"
    }
    dev = {
      name = "dev"
    }
    # prod = {
    #   name     = "prod"
    #   location = "westeurope"
    # }
  }
}

Debug Output

https://gist.github.com/msl0/7a6ec3ecd7e9fe082e9a805699c53342

Expected Behavior

The try function should be able to predict known values instead of returning (known after apply) for azurerm_availability_set.this.*.location

  # azurerm_availability_set.this["prod"] will be created
  + resource "azurerm_availability_set" "this" {
      + id                           = (known after apply)
      + location                     = "westeurope"
      + managed                      = true
      + name                         = "prod"
      + platform_fault_domain_count  = 3
      + platform_update_domain_count = 5
      + resource_group_name          = "prod"
    }

  # azurerm_resource_group.this["prod"] will be created
  + resource "azurerm_resource_group" "this" {
      + id       = (known after apply)
      + location = "westeurope"
      + name     = "prod"
    }

Actual Behavior

  # azurerm_availability_set.this["dev"] must be replaced
-/+ resource "azurerm_availability_set" "this" {
      ~ id                           = "/subscriptions/xxx/resourceGroups/dev/providers/Microsoft.Compute/availabilitySets/dev" -> (known after apply)
      ~ location                     = "westeurope" # forces replacement -> (known after apply)
        name                         = "dev"
    }

  # azurerm_availability_set.this["prod"] will be created
  + resource "azurerm_availability_set" "this" {
      + id                           = (known after apply)
      + location                     = (known after apply)
      + managed                      = true
      + name                         = "prod"
      + platform_fault_domain_count  = 3
      + platform_update_domain_count = 5
      + resource_group_name          = "prod"
    }

  # azurerm_availability_set.this["test"] must be replaced
-/+ resource "azurerm_availability_set" "this" {
      ~ id                           = "/subscriptions/xxx/resourceGroups/test/providers/Microsoft.Compute/availabilitySets/test" -> (known after apply)
      ~ location                     = "westeurope" # forces replacement -> (known after apply)
        name                         = "test"
    }

  # azurerm_resource_group.this["prod"] will be created
  + resource "azurerm_resource_group" "this" {
      + id       = (known after apply)
      + location = "westeurope"
      + name     = "prod"
    }

Steps to Reproduce

1. terraform init
2. terraform apply
3. Uncomment prod in local.apps
4. terraform plan

Additional Context

This example is simpliefied, but sometimes you want to conditionally create a dependency on the main resource and then pass it to main resource using try. You want to create some VMs with azurerm_availability_set but some without it. It's simpler to do this availability_set_id =try(azurerm_availability_set.this[each.value.vm].id, null) instead playing with conditions and lookup function

References

No response

[jbardin]

Hi @msl0,

I don't think the try function is causing what you are seeing here, because the value is statically known in the configuration, and there should be no way for it to become unknown. Trying this same reference pattern with a known well-behaved resource type (like terraform_data) also works as you would expect.

The configuration sets the location attribute for the azurerm_availability_set, which should never be planned as unknown, so this looks like a bug in the provider. If you look through the logs from TF_LOG_CORE there will probably be warnings regarding the azurerm_availability_set location attribute becoming unknown during the plan, but it's tolerated for backwards compatibility with the legacy SDK.

[jbardin]

OK, had some time to look into this in more detail. This particular config was triggering a bug in how try is evaluated in the upstream hcl package, and was fixed in #33758.

Thanks

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