search

hashicorp / terraform

Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.
https://www.terraform.io/
Other
42.35k stars 9.49k forks source link

panic: AttributeTypes on non-object Type after update to v0.13.5 from 0.12.x #28123

Closed rws2154 closed 3 years ago

rws2154 commented 3 years ago

I recently updated my version to v0.13.5 but when trying to run, ran into a panic: AttributeTypes on non-object Type. I was able to narrrow it down nd find the config that was causing this issues. It appears that if I have a module, and in that module I have this

locals {
what = "tes"
depend_1 = flatten([null_resource.cluster3])
depend = local.what == "tes" ? flatten([local.depend_1, null_resource.cluster2]) : []
#depend = flatten([local.depend_1, null_resource.cluster2])

}
resource "null_resource" "cluster" {
  count = local.what == "stests" ? 1 : 0
  # Changes to any instance of the cluster requires re-provisioning
 depends_on = [local.depend]
}
resource "null_resource" "cluster2" {
  # Changes to any instance of the cluster requires re-provisioning
  depends_on = [local.depend_1]
}
resource "null_resource" "cluster3" {
  count = local.what == "tess" ? 1 : 0
  # Changes to any instance of the cluster requires re-provisioning
}

it panics.

If I switch the depends to the other one that is commented out like this

locals {
what = "tes"
depend_1 = flatten([null_resource.cluster3])
#depend = local.what == "tes" ? flatten([local.depend_1, null_resource.cluster2]) : []
depend = flatten([local.depend_1, null_resource.cluster2])

}
resource "null_resource" "cluster" {
  count = local.what == "stests" ? 1 : 0
  # Changes to any instance of the cluster requires re-provisioning
 depends_on = [local.depend]
}
resource "null_resource" "cluster2" {
  # Changes to any instance of the cluster requires re-provisioning
  depends_on = [local.depend_1]
}
resource "null_resource" "cluster3" {
  count = local.what == "tess" ? 1 : 0
  # Changes to any instance of the cluster requires re-provisioning
}

it works fine as well, so appears to be something in depend = local.what == "tes" ? flatten([local.depend_1, null_resource.cluster2]) : [] and the

 resource "null_resource" "cluster3" {
  count = local.what == "tess" ? 1 : 0
  # Changes to any instance of the cluster requires re-provisioning
}

where the resource is not actually created, that are causing the panic.

I am attaching a small example setup that is able to reproduce the error. If run with v0.12 it plans fine, but using v0.13 it has the panic. panic.tar.gz

jbardin commented 3 years ago

Hi @rws2154,

The configuration provided does not panic in the current release. Can you confirm that 0.14 fixes the issue in the original configuration?

Thanks!

jbardin commented 3 years ago

Unrelated to this issue, I would like to point out however that this pattern does not make depends_on conditional in any way, and in general there is no need to do this. Dependencies are determined solely by the static references within the configuration.

In the first example, writing

depends_on = [local.depend]

is exactly equivalent to writing

depends_on = [null_resource.cluster2, null_resource.cluster3]
leptonyu commented 3 years ago

I have the same issue, using terraform 0.15.0

build following repo will reproduce the crash. https://github.com/leptonyu/terraform-icymint-wireguard-config-generator 

panic: AttributeTypes on non-object Type

goroutine 60 [running]:
github.com/zclconf/go-cty/cty.Type.AttributeTypes(...)
    github.com/zclconf/go-cty@v1.8.1/cty/object_type.go:187
github.com/zclconf/go-cty/cty/convert.unifyObjectTypesToMap(0xc000ad9d10, 0x2, 0x2, 0xc000739201, 0x0, 0x48ec2a0, 0xc000b295d8, 0x3, 0x3)
    github.com/zclconf/go-cty@v1.8.1/cty/convert/unify.go:368 +0x745
github.com/zclconf/go-cty/cty/convert.unifyTupleTypesToList(0xc000ad9d10, 0x2, 0x2, 0x5e89b01, 0x8, 0x18, 0x5a013c8, 0x18, 0xc000b295c0)
    github.com/zclconf/go-cty@v1.8.1/cty/convert/unify.go:487 +0x374
github.com/zclconf/go-cty/cty/convert.unifyTupleTypes(0xc000ad9d10, 0x2, 0x2, 0x1, 0x1, 0xc000ad9ae8, 0x143deb9, 0xc0006ef8c0, 0x1)
    github.com/zclconf/go-cty@v1.8.1/cty/convert/unify.go:418 +0x85d
github.com/zclconf/go-cty/cty/convert.unify(0xc000ad9d10, 0x2, 0x2, 0xc000b29501, 0x3835d80, 0x48ec2a0, 0x0, 0x0, 0x0)
    github.com/zclconf/go-cty@v1.8.1/cty/convert/unify.go:85 +0x753
github.com/zclconf/go-cty/cty/convert.UnifyUnsafe(...)
    github.com/zclconf/go-cty@v1.8.1/cty/convert/public.go:82
github.com/hashicorp/hcl/v2/hclsyntax.(*ConditionalExpr).Value(0xc0004cd8f0, 0xc000b294d0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
    github.com/hashicorp/hcl/v2@v2.9.1/hclsyntax/expression.go:576 +0x1d72
github.com/hashicorp/hcl/v2/hclsyntax.(*TupleConsExpr).Value(0xc000508fa0, 0xc000b294d0, 0x0, 0xc0006ef800, 0x1, 0x1, 0x2edfea0, 0xc000b293c8, 0x0)
    github.com/hashicorp/hcl/v2@v2.9.1/hclsyntax/expression.go:744 +0xf0
github.com/hashicorp/hcl/v2/hclsyntax.(*FunctionCallExpr).Value(0xc0000c9d10, 0xc000b294d0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
    github.com/hashicorp/hcl/v2@v2.9.1/hclsyntax/expression.go:408 +0x2406
github.com/hashicorp/hcl/v2/hclsyntax.(*ObjectConsExpr).Value(0xc000509040, 0xc000b294d0, 0x2, 0x2, 0x3, 0xc0006ef7e0, 0x2, 0x4, 0x0)
    github.com/hashicorp/hcl/v2@v2.9.1/hclsyntax/expression.go:808 +0x2ac
github.com/hashicorp/hcl/v2/hclsyntax.(*ForExpr).Value(0xc0004d12c0, 0xc000b28ea0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
    github.com/hashicorp/hcl/v2@v2.9.1/hclsyntax/expression.go:1191 +0x1017
github.com/hashicorp/hcl/v2/hclsyntax.(*ObjectConsExpr).Value(0xc0005090e0, 0xc000b28ea0, 0x0, 0xc000738c80, 0x3835d48, 0xc0001aa380, 0x3835d48, 0xc0001aa380, 0x2f27e40)
    github.com/hashicorp/hcl/v2@v2.9.1/hclsyntax/expression.go:808 +0x2ac
github.com/hashicorp/hcl/v2/hclsyntax.(*FunctionCallExpr).Value(0xc0000c9ef0, 0xc000b28ea0, 0x1, 0x1, 0x2, 0xc000738c40, 0x1, 0x2, 0x0)
    github.com/hashicorp/hcl/v2@v2.9.1/hclsyntax/expression.go:408 +0x2406
github.com/hashicorp/hcl/v2/hclsyntax.(*ForExpr).Value(0xc0004d1400, 0xc000b28e70, 0x0, 0xc000b3f900, 0x1, 0x1, 0x0, 0x0, 0x0)
    github.com/hashicorp/hcl/v2@v2.9.1/hclsyntax/expression.go:1191 +0x1017
github.com/hashicorp/terraform/lang.(*Scope).EvalExpr(0xc000d054f0, 0x5e83418, 0xc0004d1400, 0x3835d80, 0x48ec2a0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
    github.com/hashicorp/terraform/lang/eval.go:171 +0x1bc
github.com/hashicorp/terraform/terraform.(*BuiltinEvalContext).EvaluateExpr(0xc0009401a0, 0x5e83418, 0xc0004d1400, 0x3835d80, 0x48ec2a0, 0x0, 0x0, 0x0, 0xffffffffffffffff, 0x0, ...)
    github.com/hashicorp/terraform/terraform/eval_context_builtin.go:280 +0xbb
github.com/hashicorp/terraform/terraform.(*NodeLocal).Execute(0xc000a6ffb0, 0x386bd70, 0xc0009401a0, 0xc000180002, 0xc000a0bd18, 0x100d305, 0x3043880)
    github.com/hashicorp/terraform/terraform/node_local.go:153 +0x67d
github.com/hashicorp/terraform/terraform.(*ContextGraphWalker).Execute(0xc0007fc480, 0x386bd70, 0xc0009401a0, 0xd6984c8, 0xc000a6ffb0, 0x0, 0x0, 0x0)
    github.com/hashicorp/terraform/terraform/graph_walk_context.go:127 +0xbf
github.com/hashicorp/terraform/terraform.(*Graph).walk.func1(0x31c5e20, 0xc000a6ffb0, 0x0, 0x0, 0x0)
    github.com/hashicorp/terraform/terraform/graph.go:59 +0xba2
github.com/hashicorp/terraform/dag.(*Walker).walkVertex(0xc0004da240, 0x31c5e20, 0xc000a6ffb0, 0xc00061b240)
    github.com/hashicorp/terraform/dag/walk.go:381 +0x288
created by github.com/hashicorp/terraform/dag.(*Walker).Update
    github.com/hashicorp/terraform/dag/walk.go:304 +0x1246
jbardin commented 3 years ago

Thanks for the extra info @leptonyu! It would help a lot of you have the steps you used to reproduce this with a standalone example, or the complete logs if possible. I suspect this is a bug in the type unification in the upstream cty library, but we need a way to start debugging this locally.

leptonyu commented 3 years ago

@jbardin i don't know how it fails. I just keep updating terraform, and found it doesn't work now.

jbardin commented 3 years ago

Hi,

Since we have not hear back about the original issue, and the provided configuration does not panic with current terraform versions I'm going to close this out. If you have any questions, feel free to reply here or open a topic in the community forum where there are more people ready to help.

github-actions[bot] commented 3 years ago

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.