Explanation of depends_on field under prior_state in terraform plan output?

Terraform
1

The depends_on meta-arg in the resource configuration denotes explicit dependencies for the resource. The same field in present in the json output of terraform plan under prior_state section. I presume this has different meaning from the depends_on meta-arg in configuration? A few differences I can see,

  1. prior_state->depends_on seems to list both explicit and implicit dependencies (referenced via expression).
  2. prior_state->depends_on seems to list transitive dependencies as well.
  3. prior_state->depends_on seems to list dependencies resolved in the current state that the plan is producing and not really prior state that is already applied.

The last one is the most confusing because it seems like a bug? I would think prior state means the state the infrastructure is currently in, not the code. But I would like some affirmation on all the points since the docs are pretty sparse on this.

A test case to reproduce:

  1. Apply the following configuration
  2. Comment out the line below #old and uncomment all lines below #new to simulate new changes
  3. Generate json plan
  4. Retrieve dependencies of file.b using .prior_state.values.root_module.resources[] | select(.address == "local_file.b").depends_on
  5. Expected value: ["local_file.a"]
  6. Actual value: ["local_file.a", "local_file.c"]
resource "local_file" "a" {
  filename = "tmpa"
  content  = "foo"
}

resource "local_file" "b" {
  # old
  filename = "tmpb"
  # new
  # filename = "tmp${local_file.c.filename}"
  content  = local_file.a.filename
}

# new
# resource "local_file" "c" {
#   filename = "tmpd"
#   content  = local_file.a.filename
# }
#
2

Hi @akulapid,

Unfortunately the json state representation is using the wrong term for the data stored in that field, but because that json format is a stable integration point it hasn’t been changed. If you look at the native state format, that field is just called "dependencies".

The prior_state is the state immediately before the changes are going to be applied, which means that it’s been updated to match the state of the world around Terraform, and the current configuration dependencies get inserted there to make sure the state and configuration will converge. If you want the dependencies as they existed before the plan, those are in the last known state file.

Your analysis is correct though, the data in depends_on is a list of all dependencies and has no relation to the depends_on feature from the configuration. It’s really an internal implementation detail, and is primarily used by Terraform to determine the correct order of operations only when resources have been removed from the configuration.

3

Thank you for the reply. It’s very clear now.

If I wanted to get the direct dependencies (i.e. excluding transitive dependencies) of a resource, is that possible either through state file or plan output?

4

The plan output does contain a partial representation of the config, but it’s really not super useful in that it cannot represent the entire configuration structure (you can find "references" in there). Its shortcomings though are actually for the same reason what you’re asking for isn’t useful, a huge percentage of references are never “direct”. Dependency values are often abstracted through multiple layers of indirection through locals or variables, but the logical dependency is exactly the same nonetheless.

You can’t infer anything by direct references from the configuration, you always need the entire graph structure to make any meaningful assertions.

It goes even farther too. If you decide that you want only resource dependencies of the first degree, you can’t prove that that first resource isn’t just reprocessing data from an earlier dependency. In a general sense unless you know the context of how the final attribute uses the data, and where the all the data originated (it may be combined from multiple sources, static, external, etc), you always must take the entire dependency chain into account.