Variable validation of type number fails

[Wuzyn]

Terraform Version

Terraform v1.0.10
on darwin_amd64
+ provider registry.terraform.io/hashicorp/null v3.1.0

Terraform Configuration Files

variable "my_number" {
  type = number
  validation {
    condition = contains([1, 2, 3], var.my_number)
    error_message = "Failed."
  }
}

resource "null_resource" "this" {

}

Debug Output

https://gist.github.com/Wuzyn/2d3c435df178ba8147f10b8c0430d6fb

Expected Behavior

Running terraform plan/apply and providing value from condition list should pass the validation

Actual Behavior

terraform plan
var.my_number
  Enter a value: 1

╷
│ Error: Invalid value for variable
│
│   on main.tf line 1:
│    1: variable "my_number" {
│
│ Failed.
│
│ This was checked by the validation rule at main.tf:3,3-13.
╵

Steps to Reproduce

1. terraform init
2. terraform plan
3. Provide correct value, which should pass validation

Additional Context

References

[jbardin]

Thanks for filing the issue @Wuzyn!

The validation here seems to be a result of getting the input from the CLI, and it's not converted to the correct type before validation. The comparison fails because the value is still cty.StringVal("1"). It also fails when passing in the value via the -var flag.

Thanks!

[apparentlymart]

It looks like the problem here is root in some uncertainty about which component in Terraform would be responsible for evaluating variable values in the root module.

For input variable values on called modules, the whole situation is handled inside the graph node that represents each input variable: it first evaluates the variable (which includes both evaluating the expression and converting it to match the given type constraint), then records the values for use in downstream expressions, and runs the validation rules against that result:

terraform/internal/terraform/node_module_variable.go

Lines 145 to 177 in 385a3ba

	func (n *nodeModuleVariable) Execute(ctx EvalContext, op walkOperation) (diags tfdiags.Diagnostics) {
	// If we have no value, do nothing
	if n.Expr == nil {
	return nil
	}
	// Otherwise, interpolate the value of this variable and set it
	// within the variables mapping.
	var vals map[string]cty.Value
	var err error
	switch op {
	case walkValidate:
	vals, err = n.evalModuleCallArgument(ctx, true)
	diags = diags.Append(err)
	if diags.HasErrors() {
	return diags
	}
	default:
	vals, err = n.evalModuleCallArgument(ctx, false)
	diags = diags.Append(err)
	if diags.HasErrors() {
	return diags
	}
	}
	// Set values for arguments of a child module call, for later retrieval
	// during expression evaluation.
	_, call := n.Addr.Module.CallInstance()
	ctx.SetModuleCallArguments(call, vals)
	return evalVariableValidations(n.Addr, n.Config, n.Expr, ctx)
	}

The story for root module variables is a little different because Terraform Core doesn't actually evaluate those, and instead they get passed in from the caller (the CLI layer) and immediately saved for use elsewhere. The only thing that happens when we visit their graph nodes is running the validation rules:

terraform/internal/terraform/node_root_variable.go

Lines 40 to 56 in 385a3ba

	func (n *NodeRootVariable) Execute(ctx EvalContext, op walkOperation) tfdiags.Diagnostics {
	// We don't actually need to _evaluate_ a root module variable, because
	// its value is always constant and already stashed away in our EvalContext.
	// However, we might need to run some user-defined validation rules against
	// the value.
	if n.Config == nil || len(n.Config.Validations) == 0 {
	return nil // nothing to do
	}
	return evalVariableValidations(
	addrs.RootModuleInstance.InputVariable(n.Addr.Name),
	n.Config,
	nil, // not set for root module variables
	ctx,
	)
	}

In order for those to be of the correct type (matching the given type constraint) the codepath which originally populated the evaluation context would need to have done it already. However, that codepath just naively copies the raw value coming from the caller without any transformation whatsoever:

terraform/internal/terraform/graph_walk_context.go

Lines 122 to 125 in 385a3ba

	w.variableValues[""] = make(map[string]cty.Value)
	for k, iv := range w.RootVariableValues {
	w.variableValues[""][k] = iv.Value
	}

To fix this we'll need to decide which layer ought to be responsible for the step of converting the raw values from the caller to match the constraints given in the configuration, and make sure it ends up performing the same conversion step we do for internal calls, prior to checking the custom variable validation rules.

[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.