Is null_resource the only resource with triggers?

Is null_resource the only resource with triggers ?

https://registry.terraform.io/providers/hashicorp/null/latest/docs/resources/resource

Hi @gc-ss,

The triggers attribute is not special in any way, it’s an attribute of type map(string). The provider is what will indicates the resource needs replacement if there is a planned change to that attribute. You can see similar attributes for example on random_pet, with keepers, but any attribute change which the provider deems will force replacement works in this manner.

1 Like

@jbardin Appreciate the answer! I’m trying to understand whether triggers is a Meta-Argument or not?

I think not as it’s not documented under meta-arguments like:

…… but why not? Why isn’t triggers a Meta-Argument? What makes it different from one?

It is something specific to how the null_resource works and makes little sense with other resources. As the null_resource doesn’t actually manage any underlying item without the triggers once it was created nothing would ever change again. The triggers parameter allows the resource to respond to changes, causing the resource to be destroyed & recreated, impacting on any dependencies or attached provisioners.

For other resources none of this is important. They generally manage real systems and have lots of different parameters that might be changed. When the underlying item changes state or the code is adjusted to change things the resource can then detect this and make changes as needed, again triggering provisioners or impacting dependencies in certain situations.

1 Like

Right, what you said makes sense and this is why I am also confused why triggers isn’t a Meta-Argument - for majority of the resources, triggerswould result in a “no-op” and potentially only refresh the resource state but making it a Meta-Argument would bring conformity to Terraform resources

It’s possible I am missing some detail - so this is me more thinking out aloud.

A reason it’s not a meta argument is that it can be implemented as needed by any individual resource, where as options like create_before_destroy or depends_on cannot (aside from the fact that we cannot add arbitrary arguments to resources without breaking compatibility). There are many proposals for expanded lifecycle options, like Feature Request: Destructive dependencies · Issue #16065 · hashicorp/terraform · GitHub, which covers the same idea as “triggers”, but there has not yet been a clear plan devised for expanding and implementing those ideas.

1 Like