Support the `self` object in `lifecycle.precondition` for advanced input validation

[tiwood]

Terraform Version

1.7.2

Use Cases

The self object is currently only available for postcondition checks.

We currently have use cases, where we create configurations based on input YAML files. Our goal is to inform the maintainers during terraform plan if the YAML file contains invalid inputs/configurations. This could be done using lifecycle.precondition if the self object was available.

This is really similar then using input validation for variables, but this is not usable for our use case, as the input data comes from various sources (APIs, data stores..).

Attempted Solutions

N/A

Proposal

Allow the use of the self object in lifecycle.precondition.

resource "terraform_data" "this" {
  input = {
    foo = "bar"
  }

  lifecycle {
    precondition {
      condition     = self.input.foo != "foo"
      error_message = "Snap! foo should be 'foo'."
    }
  }
}

References

No response

[crw]

Thanks for this feature request! If you are viewing this issue and would like to indicate your interest, please use the 👍 reaction on the issue description to upvote this issue. We also welcome additional use case descriptions. Thanks again!

[apparentlymart]

Hi @tiwood,

The main reason this isn't currently allowed is that self refers to the result the provider returned from the request to plan changes for this object, and that request is what the precondition is intended to guard, so that value isn't available yet.

I guess from your example that you are imagining self representing something different in this context, which (with Terraform as it currently works) could in principle be either one of the following:

• The same object that Terraform Core would send to the provider as "configuration", in which only the values given directly in the configuration are populated and everything else is null.
• A special object that Terraform Core constructs as what we call the "proposed new state", which is essentially an example of something the provider could return, but in practice most providers ignore this and just construct their own "planned new state" (which is then what self represents in a postcondition).

I think the first of these is more likely to be useful because there's no guarantee that the proposed new state will match the planned new state, and so the latter could cause errant failures by checking something that Terraform would not otherwise be using.

However, it would also represent the first example of the raw "configuration" object being exposed into the language, rather than just being used as part of the provider protocol. It would mean another new concept for module authors to learn the quirks of, and would add a new meaning of self that's inconsistent with what it represents everywhere else.

I think it would also require changing the order of operations so that configuration evaluation happens before preconditions, meaning that any errors in the configuration would mask the precondition checks and that would be a breaking change for anyone who is relying on a precondition to return a better error message than Terraform would naturally generate.

With all that said then: while the use-case here does seem reasonable, it isn't clear to me that we could do exactly what you proposed, and might instead need to search for a different compromise that fits better with the current Terraform language design.

Thanks!

[jbardin]

Since we have not heard back in a while I'm going to close the issue. 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.