Make lifecycle information available to the code

[Nuru]

Terraform Version

1.3.2

Use Cases

It would be helpful when working around issues like #32023 or #16380 or other situations that crop up to be able for the code to know the state and state change of a resource during an update. Is it being created? Does it already exist? Is it being destroyed?

Attempted Solutions

One can use the time_sleep resource to specify different durations for creation and deletion and combine with time_offset to try to deduce the lifecycle phase, but that is quite a hack.

Another workaround is to create a duplicate dummy resource to ensure the data source has something to read before the real resources is created.

Proposal

Add a way to query the lifecycle of a resource. Perhaps add a read-only attribute such as lifecycle that returns a list or set of things happening to the resource in the plan. One or more of

• create
• update
• exists
• destroy
• replace

So then I can do something like

resource "aws_ssm_parameter" "example" {
  name = local.ssm_parameter_name
  value = join(",", aws_subnets.vpc.ids)
  depends_on = [data.aws_ssm_parameter.example]
}

data "aws_ssm_parameter" "example" {
  count = contains(aws_ssm_parameter.example.lifecycle, "exists") ? 1 : 0

  name = local.ssm_parameter_name
}

locals {
  old_subnets = one(data.aws_ssm_parameter.example.value)
  subnets_changed = old_subnets != aws_ssm_parameter.example.value
}

References

• Data sources should allow empty results without failing #16380
• Chained data sources fail during destroy #32023

[jbardin]

Hi @Nuru,

I think this is more or less a feature request for the provider framework. This information is generally discernible via the plugin protocol, but perhaps there are some situations which are not clear from perspective of the framework API? Do you have an example where a change on the core side of the protocol would help?

Thanks!

[jbardin]

Reading the issue again, I think I might have misunderstood your request, and are asking for this type of information to be available within the configuration. The example here is unusual, because it's trying to use a managed resource and data source to represent the same remote object, which is almost always a mistake. The problems with attempting to read information about a resource during plan and changing that resource during apply are not going to go away. You also have a dependency cycle between the managed resource and the data source, so there is no defined order of operations which can resolve the data.

Issue #16380 is something that must be implemented by the provider, because it is only the provider that can differentiate between various error conditions in the remote API. Issue #32023 is something we need to look into further. The destroy operation is a very special case of an apply operation, and there are numerous exceptions that need to be made in order for providers to be able to successfully destroy complex configurations while still retaining access to the data they need. It's unlikely that we would implement a complex mechanism which only serves to work around that problem rather than address the problem directly.

Thanks!

[jbardin]

Since we have not heard back in a while I'm going to close the issue. There doesn't appear to be anything actionable in Terraform core here, but If you have any updates regarding the issue, feel free to open a new issue with the requested information. If you have more questions, you can also use the community forum where there are more people ready to help.

Thanks!

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