terraform icon indicating copy to clipboard operation
terraform copied to clipboard

import fails for resource referenced without attribute as subsequent element of a list in a ternary expression

Open gregmark opened this issue 3 years ago • 1 comments
trafficstars

Terraform Version

Terraform v1.2.3
on darwin_amd64
+ provider registry.terraform.io/hashicorp/time v0.7.2

Terraform Configuration Files

locals {
  e = true
}

resource "time_static" "a" {
}

resource "time_static" "b" {
}

locals {
  blocks = local.e ? [time_static.a, time_static.b] : []
}

Debug Output

https://gist.github.com/gregmark/5f85a24e5688406eee5f9c9b614d2a4d

Expected Behavior

Import should have succeeded.

Actual Behavior

Crashed.

Steps to Reproduce

  1. terraform init
  2. terraform import time_static.a 2022-01-01T02:22:22Z
  3. terraform import time_static.b 2022-01-02T01:11:11Z

Additional Context

This was a bear to figure out, not knowing the underlying code. This seems to be a problem with any resource that can be imported, though I will note for completeness that I came across this while importing type aws_route53_zone resources with v1.1.9. Actions that will obscure the bug:

assign to a map instead of a list

  blocks = local.e ? {a = time_static.a.id, b = time_static.b.id} : {} 

add attribute to resource reference

  blocks = local.e ? [time_static.a.id, time_static.b.id] : []

remove ternary expression

  blocks = [time_static.a, time_static.b]

The workaround is to remove the locals assignment, though this can range from simple (commenting out a single line) to prohibitively complex (local variable is heavily referenced throughout the module).

This is a huge problem when introducing new terraform code for extant resources that cannot be recreated. For example, a state workspace for AWS resources not bound by region (route53, IAM and S3) that must persist to support an oft-changing population of region-bound resource stacks.

References

None was obvious to me.

gregmark avatar Jun 18 '22 00:06 gregmark

Hi @gregmark,

Thanks for filing the issue and the minimal reproduction! This appears to be a bug in the upstream go-cty library. We can investigate there how we inadvertently end up in object conversion from within a tuple type.

Thanks!

jbardin avatar Jun 20 '22 18:06 jbardin

Hello,

This crash appears to have been fixed in the time since the issue was filed, so I'm going to close the issue for now. If the same crash can still be found from other configuration, please feel free to reply here or open a new issue.

Thanks!

jbardin avatar Feb 06 '23 18:02 jbardin

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.

github-actions[bot] avatar Mar 09 '23 02:03 github-actions[bot]