Terraform 1.11.3 waits for hosted post-plan tasks

A completed plan does not always mean a hosted Terraform run is ready for confirmation. Post-plan tasks can still be running, and a CLI that checks readiness too soon can leave before the user has anything to approve. Terraform 1.11.3, released on March 26, fixes that behavior in the remote backend. Its other correction concerns a module containing ephemeral resources that expands to zero instances during apply.

I use Terraform because reusable configuration should make infrastructure operations understandable. Both corrections matter to that expectation. A user should be able to distinguish an operation that is waiting from one that has finished, and a disabled module should not fail because an internal graph requires a node.

Waiting is a distinct run state

The post-plan task patch identifies the sequence that caused the premature exit. During unfinished post-plan work, the remote backend reached its check for whether a run could be confirmed. The CLI could then leave before interactive confirmation or automatic application had a chance to occur. The correction explicitly waits for post-plan tasks before continuing.

The added code retrieves task-stage information for the run and polls the post-plan stage when one exists. Pending and running statuses keep the wait active. A passed stage ends the wait successfully. Canceled, errored and failed stages return errors, while a stage awaiting an override produces its own error. This preserves a distinction between work that has not finished and a stage that needs intervention.

That distinction explains the fix more precisely than calling it a retry improvement. A pending stage is expected progress through the hosted workflow. Treating its temporary inability to proceed as the end of the CLI operation makes a normal asynchronous transition look like a completed interaction. Waiting aligns the client with the service's actual readiness state.

The remote backend spans two execution locations

The remote backend documentation describes support for storing state and performing remote operations. In that model, the terminal command and the hosted execution are related parts of a workflow. The CLI is not simply evaluating a local plan and applying it in the same process.

That matters when interpreting an unexpected exit. The command's lifetime is not sufficient evidence of the remote operation's final state. Operators need the hosted run's result to understand whether the operation is waiting, failed or ready for confirmation. The patch concerns the client's handling of that relationship, with the release notes specifically identifying post-plan tasks configured in HCP Terraform.

The affected workflow can still begin with an ordinary command. A workspace using remote operations supplies the execution context for this invocation.

terraform apply

The command does not reveal whether the workspace has an additional stage between planning and application. Backend configuration and hosted run settings supply that context. This is why changing resource declarations would not address the reported defect. The problem lies in coordination around the run, after the plan has already reached the relevant stage.

A zero-instance module still needs a valid internal graph

The ephemeral-resource patch describes a separate internal assumption. Graph expansion expects a valid, nonempty graph. An ephemeral apply node could expand to zero instances, producing an empty graph that failed validation. The change adds a root node before returning the expanded graph.

The regression test adds a module call with count = 0 to an existing ephemeral-resource test. This is useful coverage because it exercises absence of instances within a configuration that still contains the relevant declaration. The correction does not manufacture an ephemeral resource to satisfy the validator. It supplies the internal root node the graph machinery requires.

This is a small code change with a specific semantic purpose. Zero resource instances must remain a valid result of expansion. A requirement imposed by an internal graph representation should not turn that valid configuration into an apply error.

Optional modules exercise real language behavior

The count documentation distinguishes a module block from the instances it declares. A whole-number count determines how many instances exist. A block can therefore remain in the configuration while declaring no instances at all, which makes conditional module instantiation a natural application of the language.

For an existing module at ./optional, a caller can express that choice directly. A boolean input controls whether the module has an instance.

variable "enabled" {
  type    = bool
  default = false
}

module "optional" {
  source = "./optional"
  count  = var.enabled ? 1 : 0
}

The example only illustrates instance selection. The March fix becomes relevant when the child module contains ephemeral resources. Terraform's earlier ephemeral-values announcement describes resources whose temporary results are opened for a phase and closed afterward, without persisting those values in plan or state artifacts. Their different lifetime requires separate execution handling, including the case where no instance exists.

As a provider author, I value a core implementation that preserves those language guarantees independently of what a provider happens to manage. The test for zero instances checks a boundary that a demonstration of successful creation would miss. Terraform 1.11.3 makes that empty expansion acceptable to the graph validator while retaining the declared absence of resource instances.