Terraform: `terraform show -json` crash

[mildwonkey]

This was originally reported in the terraform-provider-aws repository as Issue 8754

I am copying @amh-mw's report from there.

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

Terraform v0.12.0

• provider.aws v2.9.0

Affected Resource(s)

• aws_security_group
• aws_vpc

Terraform Configuration Files

Apologies for any typos; manual redactions.

terraform {
  backend "remote" {
    organization = "foo"

    workspaces {
      prefix = "foo-"
    }
  }
}

locals {
  cidr_blocks = [
    "1.2.3.4/32",
  ]

  ipv6_cidr_blocks = [
    "12::34/128",
  ]
}

resource "aws_vpc" "foo" {
  assign_generated_ipv6_cidr_block = true
  cidr_block                       = "172.0.0.0/16"
  enable_dns_support               = true
  enable_dns_hostnames             = true
}

resource "aws_security_group" "foo" {
  name   = "foo"
  vpc_id = aws_vpc.foo.id

  ingress {
    from_port        = 22
    to_port          = 22
    protocol         = "tcp"
    cidr_blocks = local.cidr_blocks
    ipv6_cidr_blocks = local.ipv6_cidr_blocks
  }

  ingress {
    from_port        = 22
    to_port          = 22
    protocol         = "tcp"
    cidr_blocks      = [aws_vpc.foo.cidr_block]
    ipv6_cidr_blocks = [aws_vpc.foo.ipv6_cidr_block]
  }

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["172.0.0.0/8"]
    # Note lack of ipv6_cidr_blocks here?
  }

  ingress {
    from_port       = 80
    to_port         = 80
    protocol        = "tcp"
    security_groups = [aws_security_group.bar.id]
    # Note lack of ipv6_cidr_blocks here?
  }
}

Debug Output

Could be provided on request. HCL above is a rather small excerpt of a larger whole.

Panic Output

https://gist.github.com/amh-mw/d09d28a26ef43c2ac0843434023aca6d

...
Plan: 0 to add, 3 to change, 0 to destroy.
Failed running command "cd /terraform; envdir /env terraform show -json /terraform/terraform.tfplan" (exit 2)
Output: panic: inconsistent set element types (
cty.Object(map[string]cty.Type{"cidr_blocks":cty.List(cty.Bool), "description":cty.Bool, "from_port":cty.Bool, "ipv6_cidr_blocks":cty.List(cty.Bool), "prefix_list_ids":cty.List(cty.String), "protocol":cty.Bool, "security_groups":cty.Set(cty.String), "self":cty.Bool, "to_port":cty.Bool}) then
cty.Object(map[string]cty.Type{"cidr_blocks":cty.List(cty.Bool), "description":cty.Bool, "from_port":cty.Bool, "ipv6_cidr_blocks":cty.List(cty.String), "prefix_list_ids":cty.List(cty.String), "protocol":cty.Bool, "security_groups":cty.Set(cty.String), "self":cty.Bool, "to_port":cty.Bool}))
                                                                                                                                                 ^
LOOK HERE ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> |

Expected Behavior

No crash.

Actual Behavior

Crash.

Steps to Reproduce

1. terraform plan

Important Factoids

Just upgraded from 0.11.4 to 0.12.0 per https://www.terraform.io/upgrade-guides/0-12.html
Running against TFE/d377923
I deleted all egress/ingress stanzas and ran plan again, same crash.

References

• None yet.

[apparentlymart]

This seems high-level similar to #21314. This is not in the same part of the codebase, but maybe the solution is similar.

[apparentlymart]

I took a quick peek at the relevant part of the code based on the stack trace, which is in the vicinity of this snippet:

https://github.com/hashicorp/terraform/blob/f68673fbe4ae7f97741a60979a56afbff6f3b53d/command/jsonplan/plan.go#L213-L227

I suspect the problem is occurring with that if !val.Type().IsPrimitiveType() branch: it's assuming that the already-transformed child object will already have been turned into a "something of bool", but it seems that at least in some cases that's not happening because in the error output we can see some lists of string.

I'm not sure if this is a bug in cty.Transform itself -- maybe it's not actually passing the already-transformed value into the callback? -- or if there's some other faulty assumption here.

[MattFenner]

I'm thinking about having a look into this issue, but I have never contributed to an open source project before or written any go, so it may take me a bit :p

edit: if someone else wants to look into this as well, go ahead. Since I will probably be slow at fixing it.

[eytanhanig]

I just hit this as well, using Terraform Enterprise. I'm glad to know that it's not just me.

[marcsauter]

I'm still fighting with this issue. Check node_cname below, it's either a list of strings or an empty list.

I built commit ff9235c4642e39255dcf1f8bc7998c1458d658ad which should contain the fix.

panic: inconsistent list element types (
cty.Object(map[string]cty.Type{"address_type":cty.Bool, "default_gw":cty.Bool, "dns_flag":cty.Bool, "ilo_flag":cty.Bool, "mgmt_flag":cty.Bool, "node_cname":cty.List(cty.String), "node_domain":cty.Bool, "node_ip":cty.Bool, "node_name":cty.Bool, "subnet_mask":cty.Bool, "subnet_prefix_length":cty.Bool, "subnet_vlan":cty.Bool})
then
cty.Object(map[string]cty.Type{"address_type":cty.Bool, "default_gw":cty.Bool, "dns_flag":cty.Bool, "ilo_flag":cty.Bool, "mgmt_flag":cty.Bool, "node_cname":cty.List(cty.Bool), "node_domain":cty.Bool, "node_ip":cty.Bool, "node_name":cty.Bool, "subnet_mask":cty.Bool, "subnet_prefix_length":cty.Bool, "subnet_vlan":cty.Bool})
)

https://gist.github.com/marcsauter/4c8177522cd4520ac5ef2e4a957be50a

[mildwonkey]

Hi @marcsauter !
I'm sorry you're still experiencing this. The commit you linked is from several days ago but the fix was only merged yesterday - can you try a build from master? Otherwise if you simply linked the wrong commit, please let us know!

[marcsauter]

Hi @mildwonkey
I just cloned the repo and built the master ... again the same result. I have updated my gist (https://gist.github.com/marcsauter/4c8177522cd4520ac5ef2e4a957be50a) with the current stack trace.

[mildwonkey]

Thank you very much (and sorry again!) for the additional validation @marcsauter!

[eerkunt]

Having a similar issue hopefully your PR will solve this problem @mildwonkey.

My stack trace is slightly different, but similar issues ;
https://gist.github.com/eerkunt/7254e1346409304554d6da255e876620

[SamirFarhat]

Hi,

I'm currently facing this issue too.

• provider.azurerm: version = "~> 1.29"

panic: inconsistent list element types (cty.Object(map[string]cty.Type{"application_id":cty.Bool, "certificate_permissions":cty.List(cty.String), "key_permissions":cty.List(cty.String), "object_id":cty.Bool, "secret_permissions":cty.List(cty.Bool), "storage_permissions":cty.List(cty.String), "tenant_id":cty.Bool}) then cty.Object(map[string]cty.Type{"application_id":cty.Bool, "certificate_permissions":cty.List(cty.Bool), "key_permissions":cty.List(cty.Bool), "object_id":cty.Bool, "secret_permissions":cty.List(cty.Bool), "storage_permissions":cty.List(cty.String), "tenant_id":cty.Bool}))

goroutine 1 [running]:
github.com/zclconf/go-cty/cty.ListVal(0xc000566f00, 0x3, 0x3, 0x201fae0, 0xc0003bc818, 0x1927ee0, 0xc00061c5a0)
/opt/gopath/pkg/mod/github.com/zclconf/[email protected]/cty/value_init.go:166 +0x4c6
github.com/zclconf/go-cty/cty.transform(0xc00080cc30, 0x1, 0x1, 0x201fa60, 0xc000761220, 0x186f280, 0xc0007dc4a0, 0x1c92180, 0x186f280, 0xc0007dc4a0, ...)
/opt/gopath/pkg/mod/github.com/zclconf/[email protected]/cty/walk.go:123 +0x6e0
github.com/zclconf/go-cty/cty.transform(0x0, 0x0, 0x0, 0x201fae0, 0xc0003bc838, 0x1927ee0, 0xc00061c6f0, 0x1c92180, 0xa50, 0x0, ...)
/opt/gopath/pkg/mod/github.com/zclconf/[email protected]/cty/walk.go:168 +0xa23
github.com/zclconf/go-cty/cty.Transform(...)
/opt/gopath/pkg/mod/github.com/zclconf/[email protected]/cty/walk.go:89
github.com/hashicorp/terraform/command/jsonplan.(plan).marshalResourceChanges(0xc00010c3c0, 0xc00058cba0, 0xc000338910, 0x0, 0x0)
/opt/gopath/src/github.com/hashicorp/terraform/command/jsonplan/plan.go:213 +0xd3b
github.com/hashicorp/terraform/command/jsonplan.Marshal(0xc000013040, 0xc0000fe0e0, 0xc000844f30, 0xc000338910, 0xc0005c8cc0, 0x1, 0x0, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hashicorp/terraform/command/jsonplan/plan.go:115 +0x345
github.com/hashicorp/terraform/command.(ShowCommand).Run(0xc00006d800, 0xc0000800e0, 0x2, 0x2, 0xc000338240)
/opt/gopath/src/github.com/hashicorp/terraform/command/show.go:167 +0xa6c
github.com/mitchellh/cli.(*CLI).Run(0xc0002ec500, 0xc0002ec500, 0xc0004f5d90, 0x1)
/opt/gopath/pkg/mod/github.com/mitchellh/[email protected]/cli.go:255 +0x1f8
main.wrappedMain(0x0)
/opt/gopath/src/github.com/hashicorp/terraform/main.go:223 +0xb06
main.realMain(0x0)
/opt/gopath/src/github.com/hashicorp/terraform/main.go:100 +0xbb
main.main()
/opt/gopath/src/github.com/hashicorp/terraform/main.go:36 +0x42

@mildwonkey : What are we supposed to do right now ? This step is crucial for our pipeline.

Thanks

[mildwonkey]

I understand that this is frustrating and I apologize to everyone running into it!

If you are experiencing this issue, as a workaround you can choose from the following:

• test the latest build from master (if you are comfortable doing so)
• use terraform show instead of terraform show -json
• downgrade to 0.11.14
• wait for a fix in the 0.12.1 release

I am leaving this open so it's easy to find for others experiencing the same bug but I believe it is fixed in master.

There is also similar-looking crash that's occurring in the _config_ rendering that you can follow here: #21543

[SamirFarhat]

Hi,

The 0.11.14 does not support -json switch. Is this expected ?
What is the release ETA for 0.12.1 ?

Samir

[hashibot[bot]]

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.