Terraform 1.1.9 renders sensitive collections safely

A sensitive element can require Terraform to hide an entire collection. Terraform 1.1.9 fixes a plan-diff crash where the renderer did not handle that situation for nested attributes. The April 20 release notes also report a fix for map keys that acquired an extra layer of quoting in displayed differences. These are presentation bugs, but they affect the information available when reviewing proposed infrastructure changes.

I depend on Terraform's plan as an explanation of what its configuration means operationally. A useful explanation must respect sensitivity while still showing which resource action is proposed. A crash during that explanation prevents review even if the underlying resource values are otherwise valid.

Sensitivity can belong to the collection

Pull request 30825 describes the affected path as rendering differences for resources with nested attribute types. The backing collection can itself be sensitive. The author identifies sensitive values in sets as the common way to encounter this, because their presence marks the entire set sensitive.

The correction checks the old and new values for that mark before descending into the nested attribute. If either value carries it, the renderer writes a sensitivity placeholder and returns from that branch. It also retains the caption indicating that the attribute forces resource replacement when that applies. Hiding a value does not remove the need to explain the action associated with it.

The tests distinguish creating a sensitive set from updating a resource whose set becomes sensitive. One case changes the sensitivity marking while retaining the same set value. Its expected output explains that the value is unchanged even though future UI output will hide it. That distinction matters because a reviewer should not have to infer an underlying data change from a change in disclosure behavior.

The test fixtures use a set of objects containing disk attributes. Their expected plan output substitutes a placeholder for the set while still rendering unrelated resource attributes. The fix therefore does not require the whole resource to disappear from the plan. It handles the collection at the level where the sensitivity mark exists.

This is consistent with the input-variable documentation available in January. That reference explains that Terraform may redact an entire nested block when revealing sibling contents could imply something about a sensitive member. A reviewer can consequently see less detail than a simple field-by-field reading of the configuration might suggest.

Sensitivity also has a narrower meaning than encryption. The same documentation says that Terraform records sensitive input values in state and sends values to providers without obfuscation. The UI's decision to hide a value is a disclosure rule for that output. This renderer repair should not be interpreted as a new storage-protection mechanism or as a change to what a provider receives.

Quoting happened twice

The second display fix has a different cause. Pull request 30855 explains that a previous change handled object keys that could not appear as bare identifiers. The map-diff path then passed the already prepared display name to a string writer, which performed its own quoting.

The result was an extra representation step. A helper made a key ready for one display context, and another helper treated that formatted text as the original string value. The patch passes the original key to the string writer and removes the intermediate display-key mapping. Its regression cases include keys containing a colon, which require quotation in the displayed syntax.

The versioned types-and-values reference gives the underlying language rule. Map keys are strings. A key may appear unquoted when it is a valid identifier, but otherwise it must be quoted. This small configuration illustrates why a display implementation needs to distinguish the key's actual characters from the quotation used to represent them.

locals {
  labels = {
    "service:owner" = "platform"
  }
}

The quotation marks in the declaration delimit the string. They are not part of the key named service:owner. A plan that adds another escaped layer can suggest that the key itself contains quotes, even though the configured value has not changed in that way.

I consider accurate key rendering especially useful in an infrastructure DSL because names often pass through several systems before an operator reads them. The plan is one place where the intended value should be unambiguous. Removing duplicate quoting makes that review possible without mentally reversing an accidental formatting transformation.

These changes address separate branches of the diff renderer. One recognizes sensitivity before traversing nested data, and the other lets a string writer perform a single quoting operation. In both cases, preserving the distinction between a value and its presentation lets the plan describe the proposed resource change more accurately.