Terraform 1.13.3 retains value metadata during validation

A variable can contain the right string while still being represented incorrectly. Terraform also tracks whether the value is sensitive or ephemeral, and evaluation must retain that metadata where it is needed. Terraform 1.13.3, released on September 17, corrects variable validation so those marks remain present while conditions are evaluated. The patch concerns the handling of a value as well as its contents.

I use Terraform's language because it can express operational intent in reusable configuration. Handling rules for values are part of that intent. A validation condition should check an input without silently losing the information that controls how Terraform may display or retain it.

A special evaluation path replaced the variable

The validation patch narrows a special case to validation walks. The existing code replaced a variable in the expression context with a potentially more-known value from Terraform's named values. That behavior supports evaluating simple validation rules in contexts where ordinary evaluation would supply an unknown value.

The replacement previously ran more broadly. The correction places it inside a validateWalk condition, preserving the normal expression context during other walks. This is a scoped change to evaluation setup. It does not remove variable validation or ask configuration authors to strip sensitivity from their input to make a condition work.

The distinction between a value's availability and its marks is important here. A value can become more concrete without that being permission to discard the rules associated with it. Copying the contents through a different internal path must preserve the metadata needed by later evaluation and diagnostics.

Sensitivity controls disclosure

The input-variable documentation describes sensitive as a control over UI output. Expressions depending on sensitive inputs are themselves treated as sensitive. The same documentation explicitly states that sensitive values can still be recorded in state. Sensitivity therefore does not mean that Terraform has stopped persisting the value.

That makes an ordinary validation rule a useful place to examine metadata propagation. A rule may compare a length or a prefix and return a boolean. The diagnostic context can still contain the original variable, even when the error message itself is a fixed string. Protecting only the final message would overlook the value retained alongside the expression that failed.

This example uses a descriptive message that contains no input interpolation. It illustrates a sensitive input with a simple condition, without presenting length as a sufficient test of whether a credential is secure.

variable "credential" {
  type      = string
  sensitive = true

  validation {
    condition     = length(var.credential) > 5
    error_message = "The credential must contain more than five characters."
  }
}

The regression checks the diagnostic's context

The released regression fixture declares a sensitive input and a length condition. The test supplies a short value so the condition fails. That failure path is necessary because the regression concerns information attached to the resulting diagnostic, not merely successful evaluation of a valid input.

The accompanying plan test checks the error description and then examines the variable in the diagnostic's expression context. It asserts that the sensitive mark remains present. This gives the correction a concrete expectation that a test checking only the error text would miss.

The value and the message can both look correct while the context is wrong. An assertion on metadata checks that additional property directly. For a language implementation, that is useful coverage because downstream presentation code depends on the information attached to values, rather than inferring sensitivity from variable names or message wording.

Ephemeral metadata has a separate purpose

Terraform's ephemeral-values announcement describes values omitted from plan and state artifacts. Their lifetime differs from an ordinary value marked sensitive for display. The September release notes name both sensitive and ephemeral metadata, so the correction should not be reduced to terminal redaction alone.

The shared implementation concern is preservation of the marks during evaluation. The policies those marks express remain different. A condition accepting an ephemeral input does not convert it into an ordinary persistent value, just as a condition accepting a sensitive input does not establish that it is safe to display.

I find this distinction useful when authoring providers and reusable modules. Input validation determines whether a value meets a condition. Metadata determines additional rules for handling that value. Neither decision should accidentally replace the other merely because the evaluator takes a special path for validation.

The released evaluator retains the special replacement where it is required for validation walks and leaves ordinary scoped values in place otherwise. This preserves the earlier ability to evaluate simple rules while repairing the broader path that lost metadata. A configuration can keep its validation condition and its handling annotations together.