Terraform 1.15.8 initializes backend aliases before provider discovery

Terraform 1.15.8, released on July 8, fixes initialization for providers whose source uses a service-discovery alias advertised by the backend. The release notes name localterraform.com as an example. A provider lookup could fail because initialization had not yet registered the alias it needed. The hostname in the source was therefore interpreted before the backend had supplied the information necessary to resolve it correctly.

I use Terraform both through its language and as a provider author. Its abstraction over APIs depends on initialization establishing the right relationships before operations begin. This failure interests me because the error looked like a remote discovery problem, while the repair concerned the order of local initialization steps. An operator needs that distinction before changing a provider source or investigating a registry.

The backend contributes discovery information

The regression report and test in pull request 38830 explain the dependency. Enhanced backends register service-discovery aliases during initialization through the shared services object. Provider discovery uses that object. If installation runs before the backend registers its aliases, discovery attempts to resolve the literal hostname instead of the intended alias target.

In the documented failure, that literal lookup returned HTML where Terraform expected a discovery document. The resulting error reported an unsupported text/html content type while querying available provider packages. That message describes the response Terraform received, but does not by itself explain why Terraform requested the wrong destination in the first place.

The report traces the regression to initialization changes in Terraform 1.15.0. Installing providers from configuration before initializing the backend removed an ordering guarantee that alias-based sources needed. The later repair restores the dependency between those operations. I would avoid treating the source hostname as independently broken without checking which Terraform version and backend initialization path produced the lookup.

This does not mean every provider lookup must rely on backend aliases. The fix concerns sources that use aliases advertised by their configured backend. That scope matters when diagnosing a similar content-type error. A public hostname serving unexpected content can have other causes, and this release note does not establish that all discovery failures share this initialization defect.

The test observes the dependency at lookup time

The regression test constructs an alias-registering backend and a provider source using the alias hostname. It supplies credentials for the target hostname in a shared discovery object. When the provider source is asked for available versions, the test checks whether credentials resolve through the alias. That verifies the alias exists at the moment discovery needs it.

This is stronger than checking whether initialization eventually registers an alias. Registering it after the provider query would leave the failure intact. The test also asserts that the watched provider discovery actually happened. Without that assertion, a changed execution path could skip the operation that was supposed to examine the ordering and still appear successful.

I would use that pattern when checking other initialization dependencies. The consumer should observe the prerequisite at the point of use. A final collection of initialized objects cannot prove that earlier consumers had access to them when they ran. Here, the provider query is the relevant observation point.

The backport explanation in pull request 38838 describes a manual combination of initialization changes. It also states which in-progress work was excluded. This makes the patch worth reading if an integration depends on the command's output. The repair brings changes to initialization behavior beyond a single conditional around a failing request.

Initialization output changes with the repair

The release notes say module installation now happens after backend initialization. They also restore the initializing_provider_plugin_message event, replacing the separate configuration and state provider initialization message types introduced earlier in the series. A human running the command will see different output ordering. Software that recognizes those event names needs to account for the change.

For an affected configuration, I would retry the normal initialization operation after upgrading the executable:

terraform init

I would keep the provider source and backend configuration intact for that verification. Changing them at the same time would make it harder to establish whether the corrected ordering addressed the original failure. Once initialization succeeds, the normal configuration checks can proceed with the provider actually installed. I would retain the earlier error and the successful initialization output together, so the verification records the same source address under both executable versions.

For an output-consuming integration, I would separately check its response to the restored event name and the new order. A successful Terraform exit does not prove that an external progress display interpreted the event stream correctly. The release explicitly identifies output changes as an expected consequence, so a parser that assumed the short-lived message split needs its own compatibility check.