`for` keyword waits for full module to be available even though it already has all necessary information

[LarsSven]

Terraform Version

1.11.3

Terraform Configuration Files

resource "openstack_dns_recordset_v2" "kubernetes_controlplane" {
  zone_id = var.dns_zone.id
  name    = "${var.cluster_name}.${var.dns_zone.name}"
  ttl     = 300
  type    = "A"
  records = concat(
    [module.primary_server.private_ip],
    [for server in module.secondary_server : server.private_ip],
  )
}

Expected Behavior

The module has a private_ip resource that is created independently of the openstack_dns_recordset_v2. However the full module cannot complete until the dns recordset is created. The recordset should be able to be created early because the private_ip of all the dependent resources are available.

Actual Behavior

While this works properly for the primary_server, for the secondary_servers the entire module must have completed before the recordset is created by Terraform. It seems that the for keywords does not generate the list of private_ips until the entire module list has been created, even though it has access to all the private_ips it needs

Steps to Reproduce

1. Create a module that has 2 resources, 1 which creates early and one which creates later
2. Create a resource that depends on a list of the early created resources
3. Note that the creation of the object gets stuck, even though all necessary resources are available.

Additional Context

Our module does not fully complete until the dns_record is present because we have a provisioner that uses the dns record. Since this is a provisioner, Terraform is obviously not aware that the modules depend on the dns record being created, which is also why this does not fail with a cyclic dependency.

References

No response

Generative AI / LLM assisted development?

No response

[jbardin]

Hello,

Without sufficient information to reproduce the issue it's hard to determine what changes you need to make, but there's nothing in the example indicating that Terraform isn't working as designed. We use GitHub issues for tracking bugs and enhancements, rather than for questions. While we can sometimes help with certain simple problems here, it's better to use the community forum where there are more people ready to help.

Thanks!

[LarsSven]

@jbardin thank you for your response. It is not a support request though, it is actually a bug / feature request (I guess a feature request is more fitting). I could make a reproducer to show the issue if you'd be willing to take a reproducer?

This is actually a very specific but very big hurdle for what we're trying to do in Terraform, as we don't really have a workaround for the issue.

[jbardin]

You are of course free to add a more complete example, but changing the rules of the how HCL is evaluated isn't possible with supported versions of Terraform..

Terraform is a declarative language where you can consider all expressions to be always be evaluated. The for keyword doesn't "wait" for anything, the simple expression [for server in module.secondary_server : server.private_ip] will always evaluate the given value of module.secondary_server (which is a single value) and return the resulting tuple. What that value is depends on how it is being generated, which was not included here. Basically, changing the semantics of for expressions cannot change when they are evaluated or what they are evaluating.

If there is a change to be made, it is probably related to #35553 rather than the expression evaluation. In that case the end result is still correct, but a slow resource could cause Terraform to apply the changes far less efficiently.

[LarsSven]

I would say that linked issue is indeed similar to what we are looking for too.

Thanks for the response.