Experiment Feedback: Input Variable Validation can cross-reference other objects

Hi everyone,

In yesterday’s Terraform CLI v1.9.0-alpha20240501 there is an experimental implementation of the long-requested feature of allowing input variable validation rules to refer to other values in the same module as the variable declaration.

For example, it allows the validation rule of one variable to refer to another:

terraform {
  # This experiment opt-in will be required as long
  # as this remains experimental. If the experiment
  # is successful then this won't be needed in the
  # final release.
  experiments = [variable_validation_crossref]

variable "thingies" {
  type = map(object({
    size = number

variable "default_thingy" {
  type = string

  validation {
    # It was not previously valid for this expression
    # to refer to var.thingies.
    condition     = can(var.thingies[var.default_thingy])
    error_message = "The default thingy must match one of the keys specified in 'thingies'."

This experimental implementation also allows referring to anything else that you would normally be able to refer to from inside the same module. We’re hoping that this full generality will work correctly, but since this is the first time we’ve allowed an input variable to refer to other items in the same module where it was declared we’d like to see folks try this out with various different kinds of references – e.g. references to data and resource blocks – to learn if there are any unexpected hazards we’ve not considered, such as tricky dependency cycles.

If you’re interested in this new capability, we’d appreciate it if you could try this out in the alpha release with some as-close-as-possible approximations of how you’d imagine using this feature in your real modules. The closer you can get to what you’d do “for real”, the better we can build confidence in the design and implementation of this feature.

Since this is only an alpha release we do not recommend using this build in production. Instead, please limit your experiments to development environments that cannot affect any infrastructure whose downtime would be detrimental to you or your organization.

If you choose to participate and have feedback to share, it would be most helpful if you could reply to this topic and include all of the relevant parts of the configuration you tried with. In particular, we’d love to see:

  • Your variable blocks containing validation blocks.
  • The declarations of whatever those validation blocks are referring to.
  • Some examples of typical ways users of your module would call it. Ideally, realistic patterns such as passing in references to resources from the calling module, rather than just hard-coded constant values.
  • If you encountered problems, the full text of any error messages Terraform returned.

I’m personally feeling pretty optimistic about this experiment since unlike most of them it’s a relatively small improvement building on other internal refactoring work we’ve been doing over the last few years, but your feedback will help us determine whether the current approach is good or whether some further design or implementation iteration is needed.

Thanks in advance for any testing and feedback!


The experiment feedback period for this feature is now over. Although we didn’t see any feedback here, reactions in other locations were positive and so we’re planning to move forward with this feature in the forthcoming Terraform v1.9.0 release.

If you try it using one of the v1.9 alpha or beta releases before final release and have feedback, please open a new GitHub issue, either as an enhancement request or a bug report depending on the nature of the feedback. We’ll then prioritize the issues to see what must be resolved before first release vs. what could potentially wait for a subsequent release.


1 Like