Terraform stops rejecting saved plans after state serialization

A saved plan can contain the same effective state as a backend while the two in-memory representations fail an equality check. Terraform 0.9.11 addresses that problem on July 3. Its release notes describe a false mismatch between state from a plan and the same state stored by the backend.

The failure follows the preceding hotfix's correction to which state copy Terraform uses during plan application. That correction preserves serial metadata advanced during persistence. It also introduced an equivalence check before accepting the backend-supplied state. Serialization can alter the representation enough to make that check fail even when the states should be equivalent.

I value the ability to review a Terraform plan before applying it. A saved plan makes that relationship explicit, so the rules connecting its snapshot to backend state need to distinguish a meaningful change from an internal representation difference.

The earlier fix selected the newer copy

The June 29 implementation explains the original sequence. Terraform persists a copy of a plan's state before applying the plan. That persistence can increment the serial number. Building the apply context from the embedded plan state would then restore the older serial.

The correction accepts state supplied by the caller when constructing the context. It falls back to the embedded state only when no state was supplied. That retains the serial associated with the persistence step instead of selecting the older metadata from the plan.

The equivalence check was meant to constrain that substitution. The code expected the supplied state to be logically equal to the embedded state, with a newer serial as the relevant difference. A failed comparison returned an error before the plan could execute.

That is a reasonable invariant to want, but its implementation depends on the equality relation matching the transformations state actually undergoes. Serialization creates a boundary at which in-memory structure may change. An equality test that is stricter than that boundary permits can reject the program's own output.

July's hotfix changes the consequence of the comparison

The 0.9.11 patch in pull request 15460 leaves the comparison in place. It changes the failed comparison from a returned error into a log entry and continues with the state already supplied. The patch's explanation identifies serialization changes as the reason the states can fail the check.

This is a precise limit on the repair. Version 0.9.11 does not introduce a new equality algorithm in this code. It stops that particular comparison from aborting apply. The error text still exists for reference in the log, while the execution context keeps using the state chosen by the preceding fix.

The distinction matters when reading a diagnostic. The presence of the mismatch message in a log does not necessarily mean the command failed at that point. In 0.9.10, that branch returned an error. In 0.9.11, it records the condition and proceeds.

Nor does this change mean Terraform has abandoned every check associated with saved plans. The patch changes one check inside plan-context construction. General claims that saved plans now ignore state consistency would extend far beyond the code in this hotfix.

A plan is a stored execution artifact

The plan documentation shipped with 0.9.11 explains how to save a plan with -out. A plan records configuration, state, the diff and variables. The state embedded in that artifact is therefore part of the execution process, not merely text printed for a reviewer.

Saving a plan separates the planning command from the later command that consumes its result. During that interval and during preparation for execution, Terraform must retain the intended relationship between the artifact and the state backend. Copying and serializing state are implementation steps inside that relationship.

The hotfix sequence shows two distinct requirements. Terraform must keep the state metadata that persistence has advanced. It must also allow its own serialization behavior without incorrectly rejecting the plan. Restoring the old state copy would undo the first correction, so July's patch instead changes how the newly added comparison affects execution.

I prefer an explanation at this level because "state mismatch" can suggest that another operator changed infrastructure. This particular failure can result from Terraform's own handling of equivalent state representations. The error's wording alone does not establish the cause.

The scope remains the plan application path

The release is a targeted hotfix, and the changelog lists this saved-plan issue as its correction. Its practical audience includes users whose saved-plan application reaches the comparison added in 0.9.10. There is no need to attribute a broader configuration-language change to the release.

The patch also preserves information for diagnosis by retaining the log message. That allows the equality discrepancy to remain observable without making it a mandatory stopping condition. The supplied state continues into the apply context, carrying the metadata that the backend path has already established.

The resulting behavior is narrower than a redesign of state persistence. Terraform 0.9.11 retains the preceding fix's choice of state copy and removes a false execution failure introduced by its sanity check. Understanding both changes explains why the release modifies logging and control flow while leaving the selected state intact.