Compacted list with resource attribute breaks plan when using count

[gieldb]

Terraform Version

v0.12.25

Terraform Configuration Files

resource "aws_security_group" "test" {
  name   = "test-sg"
  ...

  # Allow all outbound traffic
  egress {
    from_port        = 0
    to_port          = 0
    protocol         = "-1"
    cidr_blocks      = ["0.0.0.0/0"]
    ipv6_cidr_blocks = ["::/0"]
  }

}

module "test" {
  source = "../../terraform"
  ...
  allowed_sg_id = compact(concat(
    list(aws_security_group.test.id),
    data.terraform_remote_state.my_remote_state.outputs.sg_ids
  )
  ...
}

## Module
resource "aws_security_group" "default" {
  count       = var.enabled ? 1 : 0
  name        = "${var.name}_security_group"
  vpc_id      = var.vpc_id

  tags = local.tags
}

resource "aws_security_group_rule" "allow-sg" {
  count                    = var.enabled ? length(var.allowed_sg_id) : 0
  type                     = "ingress"
  from_port                = var.port
  to_port                  = var.port
  protocol                 = "tcp"
  source_security_group_id = var.allowed_sg_id[count.index]
  security_group_id        = aws_security_group.default[0].id
}

Debug Output

       Error: Invalid count argument

         on ../../terraform/sg.tf line 11, in resource "aws_security_group_rule" "allow-sg":
         11:   count                    = var.enabled ? length(var.allowed_sg_id) : 0

       The "count" 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 count depends on.

Crash Output

Expected Behavior

The variable allowed_sg_id should be passed to the module, stripped of empty tuples (compact).

Actual Behavior

It seems like the value of aws_security_group.test.id is being calculated, which is not possible before apply. Removing the compact makes terraform plan without issues.

Steps to Reproduce

Pass a compacted list with a resource to be calculated on apply, and use it in a count

Additional Context

References

[danieldreier]

@gieldb AWS resource IDs are assigned by AWS after they are created, so this information will not be available until after the test aws_security_group is created. Functions, like concat, run at the very beginning of a terraform run, before resources are created.

I understand why it would be nice to do what you're trying to do, but this is working as expected and the error message does more or less explain what's going on. I know reasoning about the order of functions vs resource creation is non-intuitive - this caught me off guard as well.

I can't quite tell whether you're asking us to put an enhancement request on our backlog, or if you're looking for guidance about how to solve this particular use case. I see two options:

1. If you are looking for immediate guidance on how to work around this, I think your best bet is to seek support on the community forum. 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. The GitHub issues here are monitored only by our few core maintainers.

2. Alternatively, if you want us to be aware of this use case and take it into consideration for future enhancements and refactors, we can label it as an enhancement request. In that case, we'd need a more detailed explanation of your use case, so we can understand your whole workflow.

Based on my work so far, I recommend you take this to the community forum for assistance in troubleshooting. I'm going to close this for now, because I think the community forum is the right approach. Feel free to leave a note or contact me at [email protected] to re-open this if you'd rather work up a more detailed workflow and file this as an enhancement request.

[danieldreier]

I just created a meta issue to track issues of this category, because I was triaging and the very next issue in the queue was basically the same category. I know this behavior isn't super obvious, but fixing it is a pretty huge refactor, so I am starting to gather data now.

[ghost]

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.