Terraform 1.3.6 removes plans for deleted orphan instances

An unchanged resource and a resource that no longer exists need different representations in a Terraform plan. Terraform 1.3.6 fixes a crash caused by keeping a no-op change for an externally deleted orphan instance that had condition checks. The November 30 release also removes redundant reconstruction of module output changes. Both repairs concern unnecessary entries in planning work, although only the first changes which resource change should exist.

The orphan-instance patch states the semantic rule directly. A no-op change should describe an object that exists and is not changing. If refresh finds that an orphaned instance has already been deleted, there is no object left for a resource action to operate on.

I want Terraform's state model to distinguish these cases accurately because a reusable infrastructure definition needs more than a count of proposed operations. Its plan should explain which objects remain managed, which are absent, and which actions still need to happen. A no-op entry for an absent object conveys the wrong premise to later processing.

Refresh can eliminate the need for an action

The patch handles an instance that has no corresponding configuration and is already absent remotely. Terraform refreshes the old state through the provider. When the refreshed value is null, the corrected path writes the refreshed result to working state and returns without constructing a resource change.

That order is significant. Removing configuration alone can require a destroy action for an object that still exists. A provider-reported deletion changes the situation because there is nothing left to destroy. The fix does not bypass deletion for a remaining orphan. It distinguishes the absent case before continuing into normal destruction planning.

The regression test checks the resulting structures separately. The refreshed state must no longer contain the resource instance, and planned changes must not contain an entry for it. Previously the test expected a no-op change. Updating that expectation records a correction to the meaning of the plan, rather than merely avoiding one failing function call.

The author explains that an earlier reason for retaining the entry may have been to leave a record for external plan consumers. By this release, plans also record changes made outside Terraform. That representation accounts for the externally observed difference without pretending that a resource instance remains available for normal processing.

This separation is useful for readers of a plan as well as for the implementation. Discovering that an object disappeared is information about the comparison with prior state. Scheduling a resource action is a decision about what Terraform still needs to do. One does not require a placeholder for the other.

Conditions made the incorrect entry consequential

The release notes identify condition checks as part of the crash scenario. The custom-condition reference introduced with Terraform 1.2 explains that preconditions and postconditions evaluate assumptions and guarantees around resource instances. Their expressions can depend on objects whose values become available at different times.

Terraform 1.3's release notes also explain why no-op instances can legitimately need condition evaluation. A resource's own planned action may be unchanged while another object's change alters the truth of its condition. The release therefore checks conditions during apply even for resource instances with no-op changes.

That behavior depends on the instance actually existing. A fabricated no-op for a deleted orphan can direct processing toward conditions for an instance that is absent. Removing the unnecessary change corrects the premise that allowed this case into later condition handling.

The distinction also prevents a misleading interpretation of the patch. Skipping checks for every unchanged resource would lose valid condition evaluation when its dependencies change. The repair is specific to an orphan that refresh has found already deleted. Existing unchanged instances and their conditions remain a separate case.

Output changes were also being repeated

The second correction, pull request 32307, changes how an output value reaches refreshed state. The output's change entry has already been established alongside current state. Updating the refreshed copy does not require establishing that change entry again.

The code previously passed both state and changes into the value-setting operation on that second path. This patch passes the refreshed state without passing the change collection. The release notes describe the old behavior as removing and re-adding module output changes, with a performance cost when output counts are large.

This is a narrower claim than faster provider operations. The work avoided here is internal bookkeeping for output changes. There is no published universal speedup in the release notes, and a configuration with few outputs need not exhibit the same cost as one with many.

I find both fixes useful for understanding the planning model. Refreshed observations and proposed changes are related, but they should not create duplicate or misleading work. Terraform 1.3.6 removes an action entry when refresh establishes that the orphan no longer exists, and it leaves an already recorded output change in place while updating refreshed state.