Resource node has no configuration attached when using "apply planfile"

[cappetta]

I'm seeing 2 issues in CI after upgrading to v0.12. Not sure if they are both related to the apply graph builder but sharing the CICD build link

I believe this is reproduced by terraform plan -out <file> then terraform apply <outfile> - I've reproduced it locally, then updated my circleci config file to eliminate the apply with a normal apply --auto-approve and the build is passing again

`
Error: Resource node has no configuration attached

The graph node for
module.staging-infrastructure.module.secdevops.aws_instance.sc[0] has no
configuration attached to it. This suggests a bug in Terraform's apply graph
builder; please report it!
`

And this error about a non-empty state:

`
Error: orphan resource module.staging-infrastructure.module.secdevops.data.aws_ami.seed_ubuntu1604 still has a non-empty state after apply; this is a bug in Terraform

[unbkbl]

I have the same problem in a CI/CD pipeline running in AzureDevops. I use the Terraform task from https://marketplace.visualstudio.com/items?itemName=ArkiaConsulting.terraform-extension

When I run a terraform plan and terraform apply from my laptop I don't that problem

I'm also using v0.12

`Error: orphan resource module.dc_uat.module.dataprovider-engine-publisher.azurerm_function_app.function still has a non-empty state after apply; this is a bug in Terraform

Error: orphan resource module.dc_uat.module.uefa-integration.azurerm_app_service.app_service still has a non-empty state after apply; this is a bug in Terraform`

[apparentlymart]

Hi @cappetta, @unbkbl! Sorry for these strange errors, and thanks for reporting them.

If either of you are able to reproduce this when running Terraform with the environment variable TF_LOG=trace set, it'd be helpful to be able to see that full trace log (via a gist, because traces are too long/verbose for github comments) so we can understand better how Terraform got itself into that "should never happen" situation.

[cappetta]

No worries, glad to share the trace logging - here's a gist

[apparentlymart]

Thanks @cappetta! We'll take a deeper look at this soon.

The first thing that seems strange to me is that the error message is talking about an orphan resource but the address it gives is for a data resource (with data. prefix) rather than a managed resource, and that is curious because the idea of "orphan" (in this sense, at least) is supposed to apply only to managed resources that have been removed from the configuration since last apply.

I suspect (but have not yet confirmed) that the main error here is the one about the node having no configuration attached, and then this other error is showing up because the first error prevented Terraform from properly processing the data resource. We'll see when we debug further whether that is accurate.

[andresvia]

@apparentlymart I have uploaded a second trace thanks.

The error seems similar to the one the OP is reporting, but is probably something different, let me know if you want me to create a separate issue.

2019/05/30 21:45:16 [ERROR] module.uw2.module.core.module.config.module.live: eval: *terraform.EvalForgetResourceState, err: orphan resource module.uw2.module.core.module.config.module.live.data.aws_caller_identity.live still has a non-empty state after apply; this is a bug in Terraform

2019/05/30 21:45:16 [ERROR] module.ue1.module.core: eval: *terraform.EvalDiff, err: Reference to undeclared module: The configuration contains no module.ue1.module.core.module.config.

2019/05/30 21:45:16 [ERROR] module.ue1.module.core: eval: *terraform.EvalSequence, err: Reference to undeclared module: The configuration contains no module.ue1.module.core.module.config.

It is also reproducible by attempting to apply a plan file, and also gets solved by apply with -auto-approve

[apparentlymart]

Hi @andresilva! Thanks for reporting that. Indeed, it does seem like something a little different, so let's open a new issue for that one and we can try to debug it separately.

[jogleasonjr]

Hi @apparentlymart

I am experiencing the same issue deploying a small piece of Azure infrastructure. Here's a gist of the output. Happy to provide any other information you need.

The auto-approve switch didn't circumvent the problem, but skipping the out parameter did.

[simoncocking]

I've raised an issue (which appears to be a dupe of this one) with full trace/plan outputs:

#21624

[bohdanyurov-gl]

Also affects us with dozens of projects. Only one module is affected though, I'm going to check what exactly leads to this error.

I can also confirm that omitting plan argument (doing plan again on apply) helps.