Destroy provisioners in removed blocks not working when associated block is removed

[rmbolger]

Terraform Version

Terraform v1.9.8
on windows_amd64

Terraform Configuration Files

locals {
  mydata = "some data"
}

resource "terraform_data" "my_resource" {
  input = local.mydata

  provisioner "local-exec" {
    command = "echo 'create' ${self.input}"
  }
  provisioner "local-exec" {
    when    = destroy
    command = "echo 'destroy' ${self.input}"
  }
}

Debug Output

https://gist.github.com/rmbolger/6f0e88f5507b24c618b8c1b9991c00c2

Expected Behavior

The destroy should have been accompanied by the destroy provisioner action such as:

terraform_data.my_resource: Destroying... [id=cbe8227f-c376-7d66-c570-f1de26bfd1ed]
terraform_data.my_resource: Provisioning with 'local-exec'...
terraform_data.my_resource (local-exec): Executing: ["cmd" "/C" "echo 'destroy' some data"]
terraform_data.my_resource (local-exec): 'destroy' some data
terraform_data.my_resource: Destruction complete after 0s

Actual Behavior

The destroy skipped the destroy provisioner and only had output such as:

terraform_data.my_resource: Destroying... [id=2f505733-2593-e3c7-b829-678d8b4f9c12]
terraform_data.my_resource: Destruction complete after 0s

Steps to Reproduce

1. Start with the provided terraform config.
2. terraform apply --auto-approve
3. Comment or remove the "my_resource" block
4. terraform apply --auto-approve

Additional Context

Prior to 1.9, one had to use workarounds like count=0 on a block during an Apply before actually removing the block in order to get the destroy-time provisioner to run. In the Terraform 1.9.0 release notes, one of the enhancements reads:

removed blocks can now declare destroy-time provisioners which will be executed when the associated resource instances are destroyed. (#35230)

I assumed this meant we would no longer be required to use the workarounds and could just remove the blocks and the cached state would still cause the last known value of the destroy provisioner to run. Is this broken or have I misunderstand what this enhancement was doing?

We are currently running on 1.9.8 in our environment. But I've tested this on 1.14.7 and the functionality has not changed.

I should also note that explicitly running apply with the -destroy switch does run the destroy provisioner. But I don't want to destroy everything in my solution, just the one block I removed.

References

https://github.com/hashicorp/terraform/blob/v1.9/CHANGELOG.md
#35230

Generative AI / LLM assisted development?

n/a

[rmbolger]

My apologies. I just realized there's a difference between removing a block from your configuration and the literal removed block which is what the enhancement seems to have been referring to.

Is there still no way to get destroy-time provisioners to run when simply removing the block from the configuration?

[jbardin]

Hi @rmbolger,

Yes, if you remove the provisioner from the configuration, there is no longer any configuration for that provisioner, hence nothing for Terraform to run. If you want to remove the resource block yet retain the provisioner, you need to move the provisioner to a removed block.

[rmbolger]

This is ultimately part of a module that internal users in our org reference. So they just declare the module reference, and internally it's creating the terraform_data resources with the provisioners. The goal is that they don't have to care about the underlying implementation and when they want the module resources gone, they just remove the module block. But there doesn't seem to be a way to allow them to do that and still have the cleanup executed by the destroy-time provisioner.

Here's what I don't really understand. The terraform state contains the details about the deployed resource so that when you remove it from the config, it uses that cached state to know what to destroy. Why aren't the provisioners part of that cached state such that even though the configuration has been removed, the engine still knows it has a destroy provisioner to run?

[jbardin]

The design of provisioners was frozen a long time ago, and their use has been discouraged in various ways over the years (the current docs page starts with a red warning box). In order for something to be executed when entirely removed from the configuration it must be stateful, and the original design of provisioners was specifically not stateful (primarily because they often relied on credentials which should not be in the state). There could be something else designed to take that place, and there is some work being done currently in the area of actions, but proposed workflows around destroy still haven't been ironed out.

The most reliable way to ensure something is done within the Terraform workflow is to use a managed resource directly, rather than indirectly through a provisioner. Writing a custom resource does require some extra work up front, but I have also seen some more generic community providers that can run ad-hoc commands at each lifecycle phase be used for similar purposes.