Feature Request: Support when = "destroy" for aap_job

[akli-ime]

Description:
Currently, the AAP provider supports launching jobs using the aap_job resource, for example:

resource "aap_job" "sample_bar" {
  job_template_id = 7
  inventory_id    = aap_inventory.my_inventory.id
  extra_vars      = jsonencode(yamldecode(local.values_extra_vars))

}

However, there is no way to configure a job to run only on destroy.
This is important for teardown workflows where you need to call an AAP job template to remove infrastructure or clean up environments.

Proposed Solution:
Add a when argument to the aap_job resource.

Example (proposed syntax):

resource "aap_job" "sample_destroy" {
  job_template_id = 12
  inventory_id    = aap_inventory.my_inventory.id
  extra_vars      = jsonencode(yamldecode(local.destroy_extra_vars))

  when = "destroy"
}

Behavior:

when = "apply" (default): job launches on apply (current behavior).
when = "destroy": job launches only when the resource is being destroyed.

Benefits:

• Enables clean teardown workflows directly in Terraform.
• Keeps syntax consistent without introducing a separate aap_destroy_job resource.

There is strong precedent:
The [hashicorp/terraform-provider-http#558] proposal introduced a similar when argument to control whether HTTP requests run during apply or destroy. Aligning with this approach makes provider behavior more predictable and familiar for Terraform users.

Thank you in advance for considering this feature!

[dleehr]

Hi @akli-ime, thanks for opening the issue and taking the time to explain the desired behavior. I recognize the use case is a tricky gap between Terraform and Ansible. There's certainly a case for running Ansible automation after destroying Terraform resources. Both companies are aware of that gap, so please stay tuned.

On this particular request, I think it would be confusing behavior for the provider to create a resource (an AAP Job) when the user has executed a terraform destroy and agreed to destroy all resources.

I see that you referenced a PR hashicorp/terraform-provider-http#558 as precedent, however that does not appear to be reviewed or merged yet. Do you have evidence of other terraform providers that actively implement such a pattern?

[akli-ime]

Hi @dleehr , thank you for the thoughtful reply and for clarifying the concerns around this behavior.

To clarify our use case: our workflows depend on Ansible to register resources in internal company directories that lack Terraform providers. When resources are destroyed, we must also remove those records via the Ansible API. Without this, our directories accumulate stale entries, leading to inconsistencies.

Regarding precedent : while I understand the concern about creating resources during terraform destroy, there are providers that implement similar patterns for cleanup:

1. devops-rob/terracurl (destroy_url) https://registry.terraform.io/providers/devops-rob/terracurl/latest/docs/resources/request
2. Mastercard/restapi (destroy_method and destroy_path) https://registry.terraform.io/providers/Mastercard/restapi/latest/docs/resources/object

Both implement patterns where cleanup actions are triggered as part of terraform destroy, which is similar to what we’re aiming to achieve with AAP Jobs.

I completely see the concern about Terraform destroying resources while the provider creates a new one in that process. However, in this scenario, the job itself isn’t a persistent resource, it’s more of an ephemeral action to finalize cleanup. That’s why we believe it aligns with the intent of destroy.

Would it be acceptable to explore an opt-in configuration flag (e.g. run_on_destroy = true) so that only users with this explicit need enable the behavior? This could mitigate confusion while still addressing real-world gaps between Terraform and Ansible.

Regards

[rmcolbert]

We have a similar situation. Our workflows are configured to have a create template and a destroy template (with compatible options). An option that would work for us would be something like "on_destroy_template_id" as part of the resource so the normal destroy action just kicks off a different template id ... or add something the terraform_data provisioner's "when = destroy" flag.