Terraform plan crashes after adding an output to a module

reifnir commented 3 years ago

Adding an output to my module causes terraform plan or apply to crash.

Terraform Version

I can confirm that terraform plan does not crash with Terraform 0.15.0-beta1.

Terraform v0.15.0-beta2
on linux_amd64
+ provider registry.terraform.io/hashicorp/archive v2.1.0
+ provider registry.terraform.io/hashicorp/azurerm v2.52.0
+ provider registry.terraform.io/hashicorp/local v2.1.0
+ provider registry.terraform.io/hashicorp/null v3.1.0
+ provider registry.terraform.io/hashicorp/random v3.1.0

Terraform Configuration Files

Adding the following output to a module I'm working on causes Terraform 0.15.0-beta2 to crash.

output "default_hostname" {
  value = azurerm_function_app.static_site.default_hostname
}

Debug Output

Crash Output

I'm providing a complete (secrets redacted) log of the terraform plan step that succeeds when the default_hostname output is not present from the module in an attachment named plan-without-output.log.

Also the crash log. crash.081200382.log

Expected Behavior

Terraform plan is able to execute without crashing

Actual Behavior

Terraform plan crashes

Steps to Reproduce

Pull down my project here https://github.com/reifnir/terraform-azurerm-azure-functions-static-site
Navigate to ./examples/simple-example-static-site
Initialize and run the Terraform plan

Additional Context

This module probably has a weird dependency graph due to the resource_null step that creates the contents of a package followed by a data.archive_file that creates the zip file that will be uploaded to an Azure Blob.

There is also some potentially weird use of timestamp dependencies in the project root ./main.tf file (since there's no easy way to add a number of years to a timestamp).

This crash is happening in plan, but just a heads-up. The location for temporary files when building that zip file is in a directory under .terraform

# Until/unless Terraform provides a simpler `path.temp` capability, this is a workaround for creating
#   A temporary directory
#   That does not get cleaned-up after multiple jobs (boo)
#   With no possibility of file collissions for previous builds
# See: https://github.com/hashicorp/terraform/issues/21308#issuecomment-721478826

References

None

apparentlymart commented 3 years ago

Hi @reifnir! Sorry for this crash, and thanks for reporting it.

It seems like the stack trace of this particular panic is self-contained enough to be useful to narrow down the problem without referring to the rest of the log, so I'm going to copy it into here for easier reference:

panic: can't use ElementIterator on unknown value

goroutine 602 [running]:
github.com/zclconf/go-cty/cty.Value.ElementIterator(0x2c020b8, 0xc000c8b5e0, 0x23a6120, 0x3caae20, 0xc0006dae40, 0xd)
    /go/pkg/mod/github.com/zclconf/go-cty@v1.8.1/cty/value_ops.go:1113 +0x13b
github.com/hashicorp/terraform/terraform.getValMarks(0xc000a1b740, 0x2c02128, 0xc000c8b9d0, 0x23cfa00, 0xc001e99860, 0x0, 0x0, 0x0, 0x2020002, 0x3, ...)
    /home/circleci/project/project/terraform/evaluate.go:992 +0x6c5
github.com/hashicorp/terraform/terraform.markProviderSensitiveAttributes(0xc000a1b740, 0x2c02128, 0xc000c8b9d0, 0x23cfa00, 0xc001e99860, 0x2c02128, 0xc000c8b9d0, 0x23cfa00, 0xc001e99860)
    /home/circleci/project/project/terraform/evaluate.go:959 +0x6e
github.com/hashicorp/terraform/terraform.(*evaluationStateData).GetResource(0xc000a7f9e0, 0x4d, 0xc00014f3f8, 0x14, 0xc000ac5290, 0xb, 0xc000ac4960, 0x10, 0x2, 0xb, ...)
    /home/circleci/project/project/terraform/evaluate.go:762 +0xbd5
github.com/hashicorp/terraform/lang.(*Scope).evalContext(0xc000b0aaa0, 0xc000b18840, 0x1, 0x1, 0x0, 0x0, 0x0, 0x0, 0x901c57, 0xc00075c170)
    /home/circleci/project/project/lang/eval.go:360 +0x206d
github.com/hashicorp/terraform/lang.(*Scope).EvalContext(...)
    /home/circleci/project/project/lang/eval.go:238
github.com/hashicorp/terraform/lang.(*Scope).EvalExpr(0xc000b0aaa0, 0x2c00fe0, 0xc000420f60, 0x2c02080, 0x3cab320, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
    /home/circleci/project/project/lang/eval.go:163 +0xb6
github.com/hashicorp/terraform/terraform.(*BuiltinEvalContext).EvaluateExpr(0xc0013dd2b0, 0x2c00fe0, 0xc000420f60, 0x2c02080, 0x3cab320, 0x0, 0x0, 0x40, 0x7f068f1eb108, 0x40, ...)
    /home/circleci/project/project/terraform/eval_context_builtin.go:280 +0xbb
github.com/hashicorp/terraform/terraform.(*NodeApplyableOutput).Execute(0xc000f75e40, 0x2c37770, 0xc0013dd2b0, 0xc000142002, 0xc000f8fd18, 0x40bb05, 0x2418a80)
    /home/circleci/project/project/terraform/node_output.go:272 +0x8e4
github.com/hashicorp/terraform/terraform.(*ContextGraphWalker).Execute(0xc0002d8a80, 0x2c37770, 0xc0013dd2b0, 0x7f0667ef63d0, 0xc000f75e40, 0x0, 0x0, 0x0)
    /home/circleci/project/project/terraform/graph_walk_context.go:127 +0xbf
github.com/hashicorp/terraform/terraform.(*Graph).walk.func1(0x25e8de0, 0xc000f75e40, 0x0, 0x0, 0x0)
    /home/circleci/project/project/terraform/graph.go:59 +0xba2
github.com/hashicorp/terraform/dag.(*Walker).walkVertex(0xc000421920, 0x25e8de0, 0xc000f75e40, 0xc000f75ec0)
    /home/circleci/project/project/dag/walk.go:381 +0x288
created by github.com/hashicorp/terraform/dag.(*Walker).Update
    /home/circleci/project/project/dag/walk.go:304 +0x1246

Based on this stack trace, it seems like this problem arises from a collision between the fact that parts of a resource instance object can be unknown during planning and the need to apply "sensitive value" marks to values coming from attributes that the provider marked as sensitive. While it doesn't seem that you're referring directly to a sensitive value here, Terraform needs to build the object value representing the whole of azurerm_function_app.static_site in order to evaluate that expression, and I guess there's some other sensitive attribute of that resource type which is within an a value that happens to be unknown for this particular object.

apparentlymart commented 3 years ago

I've labelled this as related to the "provider_sensitive_attrs" experiment, even though you aren't using that here, because I think the codepath that led to this panic is what was previously activated by that experiment and which has been made stable (not experimental) for v0.15. I'm not 100% sure about that but this label may make it easier to find along with the other feedback about that experiment, if so.

reifnir commented 3 years ago

Added a tag in case you want to replicate this in the future as the main branch is moving on from this state

https://github.com/reifnir/terraform-azurerm-azure-functions-static-site/releases/tag/tf-0.15.0-beta2-bug-28153

ghost 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.

hashicorp / terraform