Include a specific -target argument in "Invalid count argument" and "Invalid for_each argument" error messages

[canozokur]

Hello!

Thanks for keeping Terraform updated with fantastic additions, like for_each expressions. But I think for_each expressions should be more informative with its errors. Let's see the use case and let me explain if I can.

Use-Case

Suppose on Amazon we're creating two instances, a LB target group and try to attach those two instances to the target group.

resource "aws_instance" "webserver" {
  count                       = 2
  ...other arguments...
}

resource "aws_lb_target_group" "webserver" {
}

resource "aws_lb_target_group_attachment" "webserver" {
  for_each = toset(aws_instance.webserver[*].id)
  target_group_arn = aws_lb_target_group.webserver.arn
  target_id = each.value
  port = 80
}

This, of course, causes the following error because we still don't know the instance IDs. They are not yet created.

Error: Invalid for_each argument

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.

Okay, fine. We can find the for_each and its dependency on aws_instance.webserver resource easily because we don't have many resources (or modules). Imagine doing this in a lot of resources.

I think if Terraform somehow can inform the users which line this for_each resides on or (even better) which resource they need to -target first, this would go really smoother for them. No more searching for every for_each expression to see which resource they may have referred (which is not created, yet).

Thanks!

[teamterraform]

Hi @canozokur! Thanks for sharing this.

Some good news is that we found and fixed the missing source location indication for this error message just yesterday (in #22760), so that should be better in the very next release.

For the extra information in the error message: we agree that it would be most helpful to give a specific argument value to use here. Indeed, we attempted to implement something like that during the initial 0.12.0 development for the equivalent of this message when using count. Unfortunately Terraform doesn't currently have enough information at the point where this error is returned to work backwards to find which targetable objects would help, and so we were unable to implement it so far.

Improving this error message would likely require first implementing #2253, so that the error message could then suggest simply to exclude the resource that produced the error, perhaps like this (depending on what final syntax we select for inverse targeting):

-target="!aws_lb_target_group_attachment.webserver"

The other possibility is that #4149 might come first, in which case this error message would go away completely in favor of Terraform automatically deferring this resource until a second plan/apply cycle. Both of these features require some similar graph-level work and we have some graph-level work coming soon to address some other problems in this area, so we might find (though definitely remains to be seen) that #4149 can come first and make #2253 unnecessary here.

Either way, this is unfortunately not something the Terraform team at HashiCorp will be able to prioritize in the very near future due to current priorities being elsewhere, but we'll keep it in mind when we shift our focus onto graph-related changes.

[apparentlymart]

As part of resolving #30937, the two error messages discussed in this issue are going to be removed altogether in favor of Terraform automatically detecting that certain resources cannot be planned and automatically "deferring" their actions to a future plan.

What we're implementing for that is essentially the same as what was proposed here except that rather than just telling the user what to target and making them run a separate command to achieve it Terraform will use its conclusion to automatically skip planning what it can't plan. This won't be exactly the same as -target because Terraform will still visit and shallowly-validate the resources in question, but it'll achieve a similar result.

Therefore I'm going to close this issue just to consolidate it with the broader issue that'll eventually address it.

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.