transitive dependencies can be missed when there are no instances to apply

[jbardin]

Terraform Version

Terraform v1

Terraform Configuration Files

resource "terraform_data" "one" {
}

resource "terraform_data" "two" {
  count = 0
  depends_on = [terraform_data.one]
}

resource "terraform_data" "three" {
  depends_on = [terraform_data.two]
}

Debug Output

  provider["terraform.io/builtin/terraform"] - *terraform.NodeApplyableProvider
  provider["terraform.io/builtin/terraform"] (close) - *terraform.graphNodeCloseProvider
    terraform_data.one - *terraform.NodeApplyableResourceInstance
    terraform_data.three - *terraform.NodeApplyableResourceInstance
  root - *terraform.nodeCloseModule
    provider["terraform.io/builtin/terraform"] (close) - *terraform.graphNodeCloseProvider
  terraform_data.one - *terraform.NodeApplyableResourceInstance
    terraform_data.one (expand) - *terraform.nodeExpandApplyableResource
  terraform_data.one (expand) - *terraform.nodeExpandApplyableResource
    provider["terraform.io/builtin/terraform"] - *terraform.NodeApplyableProvider
  terraform_data.three - *terraform.NodeApplyableResourceInstance
    terraform_data.three (expand) - *terraform.nodeExpandApplyableResource
    terraform_data.two (expand) - *terraform.nodeExpandApplyableResource
  terraform_data.three (expand) - *terraform.nodeExpandApplyableResource
    provider["terraform.io/builtin/terraform"] - *terraform.NodeApplyableProvider
  terraform_data.two (expand) - *terraform.nodeExpandApplyableResource
    provider["terraform.io/builtin/terraform"] - *terraform.NodeApplyableProvider

Expected Behavior

The instances should always be created in the order terraform_data.one -> terraform_data.three

Actual Behavior

There is no order enforced between the creation of instances one and three,

Steps to Reproduce

terraform apply

Additional Context

What is happening is that terraform_data.three does depend on the terraform_data.two configuration being evaluated, but there are no instances planned to go long with that evaluation. Because there are no terraform_data.two instances there is nothing to connect the terraform_data.three instances with the terraform_data.one instances. The terraform_data.two config (the config is represented by (expand) here) does depend on terraform_data.one (expand) node, but that does not depend on the terraform_data.one instances because that dependency travels in the inverse direction.

This results in the configuration evaluation happening in the correct order, but the actual resource instances may be applied in a different order. This doesn’t normally matter because once once the configuration is complete most resources can be applied without a problem, but depends_on is also used to represent dependencies outside of terraform which are not visible via the instance configuration.

[apparentlymart]

Ahh, the differences between plan and apply graphs strike again.

In the long run I expect (as you've often argued) we'll reunify the plan and apply graphs to be constructed in a more similar way again, but as a short-term fix could we change the DiffTransformer to create nodes even for "no-op" actions and just use a node type that quickly returns without doing anything so that the delay is (hopefully) negligible?

That's the lowest-risk change that comes to my mind since it doesn't introduce anything new that couldn't potentially have happened some other way: it's always possible that all of the instances have real changes planned, so the system must presumably already be able to handle a graph where all instances are present. I'm sure there are other similar surgical fixes, though.

[jbardin]

A placeholder might be a good way to do this, though we don't currently even have noop changes for instances that don't exist to give to the DiffTransformer (adding all possible NoOps back in even with a dedicated NoOp node type still presents graph scaling issues).

Another option is to ensure the (expand) nodes are connected to all the config dependencies' instances by the ReferenceTransformer. These may not be connected only as a simplification rather than out of necessity.

[apparentlymart]

Oh yes, that's a good point: if there are zero instances then there are no changes at all in the plan, so we'd need to refer to the configuration to know that those resources even existed at all. But if we already have the "expand" nodes in the apply graph (even though the instances for each resource are already pre-expanded in the plan anyway) then that's even better, since that's then closer to the shape of the plan graph.

[github-actions]

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.