Terraform 1.1.6 makes command failures explicit

An error message does not necessarily stop the program that invoked a command. Terraform 1.1.6 fixes a case where terraform state mv reported missing resources but returned success to its caller. The February 16 release also prevents complex uses of the console's type function from crashing Terraform. Both bugs concern how a command communicates failure, although their causes sit in different parts of the implementation.

I regard predictable command behavior as part of Terraform's usefulness as an infrastructure language. Configuration reuse is less valuable when the tools around it cannot distinguish a completed operation from a rejected one. The state-command correction is particularly relevant to automation because the visible message and the process result previously disagreed.

State moves have a machine-readable result

The state-move documentation included in this release describes state as the association between Terraform addresses and remote objects. Moving a binding tells Terraform to track an existing object under a different address. It is useful when renaming a resource or moving its configuration into a module while retaining the remote object.

For example, a rename can pair a configuration change with a command using the old and new resource addresses. This example follows the documented resource-rename operation.

terraform state mv packet_device.worker packet_device.helper

The source has to exist in the current state for that operation to perform the intended move. Before this patch, Terraform could explain that the specified resources were absent and still return a successful exit status. Version 1.1.6 returns error code 1 in that case. A wrapper that already checks command status can now detect the failure through its normal control flow.

The operational implication follows directly from that mismatch. A process that advances to another step only after success could previously advance even though no matching resource had moved. Reading the console output manually might reveal the problem, but an automated caller should not need to interpret diagnostic wording to recover the failure status. The fix brings those two outputs into agreement.

This does not make arbitrary state-address changes valid. The versioned command documentation requires source and destination to refer to compatible kinds of objects. Moving a resource instance to another instance also requires the same resource type. A change in the exit code cannot turn an incompatible address transformation into a supported operation.

Address syntax remains relevant too. Resources using count have integer instance keys, and resources using for_each have string keys. The documentation shows quoting those addresses so that the shell passes brackets and embedded quotes to Terraform correctly. An address that looks familiar on screen still has to reach the command with its intended characters intact.

The command changes state bindings separately from configuration edits. Its documentation therefore calls attention to coordination when other users can operate on the same workspace. Between changing a resource declaration and moving the binding, another plan could interpret the unmatched addresses as a deletion and creation. Correct failure reporting makes an unsuccessful move detectable, but it does not combine those separate operations into one transaction.

Type inspection is a console operation

The other correction starts with a convenience of interactive debugging. The versioned type-function reference describes type as a console-only function for examining how Terraform interprets a value. It helps explain errors involving incompatible conditional results or unfamiliar nested structures. The intended use is a top-level inspection.

type("example")

The console displays string for that expression. Treating the result as ordinary expression data, however, was outside the intended contract. The implementation change in pull request 30476 explains that the earlier implementation used a marked value to request raw display without normal HCL string quoting.

Marks can propagate through expression evaluation. A formatting instruction that makes sense for one display value could consequently reach a collection, where iteration over the marked value caused a crash. The problem came from allowing an internal representation intended for console display to participate in expressions that the display code did not support.

The patch introduces a dedicated internal capsule type for type information and checks the result in the console session. Its tests cover ordinary inspection and rejected combinations, including a comprehension that calls type for each element. The release notes describe the resulting behavior as a diagnostic error for complex use instead of a crash. This restriction keeps the inspection tool available without suggesting that Terraform configurations now have general runtime type reflection.

I prefer that explicit limitation to a debugging convenience with accidental expression semantics. A console function can be useful without becoming a configuration-language facility. For someone investigating a module's input types, the supported workflow remains examining the relevant value directly. For a script that moves state, the supported failure signal now includes the nonzero status that the missing-source diagnostic should have carried all along.