Computed module output is not forcing new on dependent resource

[jcarlson]

Terraform Version

$ terraform -v
Terraform v0.12.25
+ provider.null v2.1.2

Terraform Configuration Files

# ./module/main.tf

variable "name" {
  type = string
}

resource "null_resource" "resource_in_module" {
  triggers = {
    name = var.name
  }
}

output "id" {
  value = null_resource.resource_in_module.id
}

# ./main.tf

module "foo" {
  source = "./module"
  name   = "some-value"
}

data "null_data_source" "data_in_root" {
  inputs = {
    id = module.foo.id
  }
}

resource "null_resource" "resource_in_root" {
  triggers = data.null_data_source.data_in_root.outputs
}

Expected Behavior

Changing the value of the name variable for module foo should cause module.foo.null_resource.resource_in_module and null_resource.resource_in_root to both be replaced in one execution of terraform apply.

Actual Behavior

Changing the value of the name variable for module foo causes only module.foo.null_resource.resource_in_module to be replaced; you must run terraform apply a second time in order for Terraform to detect and replace null_resource.resource_in_root.

Steps to Reproduce

1. terraform init
2. terraform apply
3. change the value for name on module foo in the root
4. terraform plan
5. observe that only module.foo.null_resource.resource_in_module is marked for replacement

Additional Context

I have observed this on a couple of different resource and data types. This was the simplest configuration that exhibited this behavior.

If you were to flatten the project structure so that all data and resource blocks were in the root, and no modules were in use, then everything would work as expected. So the issue here is with the way that module outputs are used as inputs to data sources.

The dependency graph generated here seems to suggest that the dependencies are properly recognized, but somewhere, when the output of a module is used as the input to a data resource, and that output is computed and/or is known to change, that seems to be lost in translation.

For example, the following structure resolves this issue:

variable "name" {
  type = string
  default = "foobar"
}

resource "null_resource" "resource_in_module" {
  triggers = {
    name = var.name
  }
}

data "null_data_source" "data_in_root" {
  inputs = {
    id = null_resource.resource_in_module.id
  }
}

resource "null_resource" "resource_in_root" {
  triggers = data.null_data_source.data_in_root.outputs
}

References

• Data Resource Lifecycle Adjustments #17034

[danieldreier]

@jcarlson this is a really well written issue report. Thanks! I need confirmation from @jbardin but I believe that the cause of this is that data sources are currently evaluated first, and are not part of the graph.

Fortunately, @jbardin is making v0.13.0-targeted changes to have module data sources participate in the graph, so that module depends_on works with data sources as you would expect. If I'm understanding this issue correctly, I think that this should work as you expect in the 0.13.0 beta we'll be releasing on June 3rd.

[jcarlson]

@danieldreier Thanks! After I submitted the issue, I went hunting for related issues. I couldn't believe that no one else had run into this issue. Indeed, #17034 does appear to explain the root cause in much more gory detail than I have here.

Still, it was interesting that flattening the structure of the project seemed to resolve the issue. According to the information in #17034, I would not have expected that to be the case.

[jbardin]

Yes, this is fixed by #24904, which allows data sources to be re-evaluated during plan.

As for why flattening the config works in this case, there was check in place to catch this type of relationship in the simplest case, which is when the data source directly referenced another resource.

[danieldreier]

@jcarlson I'm going to resolve this because it's fixed in 0.13 and the beta for that comes out next week. Thanks for reporting it and I'm glad we had a fix already in the works!

[ghost]

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.