Complex module outputs seemingly considered `null` instead of computed during plan

Terraform
1

I have a module for deploying AWS Route53 Application Recovery Controller (ARC) which is a set of monitoring services for watching other AWS resources (LBs, Auto-Scaling Groups, etc). The app stack is a dependency for ARC because the resource ARNs are set for monitoring to occur.

When I attempt to build the application stack (a module) and ARC (a module) in the same Root Module, the outputs values of the app stack are passed to the ARC module “implicitly” and are used to determine which services are intended to be set using a local. however, the computed values are throwing off locals logic.

It would be very simple to run these modules in separate roots, but, I’m struggling to understand why this doesn’t work… Any input would be helpful.

Here is a link to the root module that causes the issue: include sample app deployment for testing by drewmullen · Pull Request #6 · aws-ia/terraform-aws-route53-recovery-controller · GitHub

reproduce:

git clone git@github.com:aws-ia/terraform-aws-route53-recovery-controller.git
git checkout sample-app
cd examples/basic
terraform init
terraform apply

error:

│ Error: Invalid for_each argument
│ 
│   on ../../modules/readiness_recovery_group/main.tf line 19, in resource "aws_route53recoveryreadiness_resource_set" "each_region_per_service":
│   19:   for_each = toset(var.service_list)
│     ├────────────────
│     │ var.service_list is a list of string, known only after apply
│ 
│ The "for_each" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work
│ around this, use the -target argument to first apply only the resources that the for_each depends on.
2

Ive been latently considering this problem more and I have 2 ideas to try:

  1. the local.service_list compares key entries to != null because I used to use terraform custom objects…

  2. The problem could be due to the fact that I’m passing the local to a submodule as a variable. Variables in TF are treated differently at plan and are not capable of waiting. hence why the error is related to the ARC sub-module var.service_list and not the root module local.service_list where the list is initially calculated. I may try to extract the resources from a sub-module and see if that fixes it…

3

holy cow. #1 was it. problem solved. huzzah!