Terraform 1.9.8 identifies missing module subdirectories

A registry module can download correctly while the requested module inside its package does not exist. Earlier Terraform initialization errors could classify that situation as a bug in Terraform itself. Version 1.9.8 distinguishes a missing requested subdirectory from a package installation that cannot be read, giving the error a more useful explanation.

The 1.9.8 release, dated 16 October, also repairs invalid provider metadata handling, generated map keys and provider validation against state. The tagged changelog groups these changes as bug fixes. Their common practical benefit is preserving the context needed to diagnose a configuration-processing failure.

I value Terraform's module distribution model because infrastructure definitions can be reused without copying their implementation into every configuration. That benefit depends on knowing which part of module resolution failed. An error that blames the executable when the requested path is absent sends the investigation toward the wrong cause.

Package installation and module selection differ

The module diagnostic patch in pull request 35848 acts after the registry package has been installed. Terraform attempts to load the selected configuration directory. A nil result means the directory is missing or unreadable, but that result alone does not establish why.

Before this change, Terraform replaced the loader's diagnostics with a message describing the unreadable directory as a Terraform bug. The implementation assumed that creating an installed registry directory was Terraform's responsibility. That assumption overlooked a source address that successfully selects a package but also names a nonexistent path within it.

The corrected code checks whether a subdirectory was requested. It then separately examines the installed package path and the selected module path. If the package exists and the selected directory does not, Terraform emits a specific missing-subdirectory diagnostic. Other unreadable-directory cases retain the existing broader explanation.

The regression fixture requests a registry module with a //modules/child_c suffix. Its test checks that the diagnostic explicitly identifies the absent target. That distinguishes a failure to retrieve the package from a failure to find the chosen configuration inside the retrieved package.

This is a diagnostic correction, not a new source-address format. It does not make absent content available or change which module a valid path selects. It makes the difference between installation and selection visible at the point where the operator needs to act on it.

Invalid metadata should stop decoding

The provider metadata fix in pull request 35842 concerns a different boundary. Terraform checks whether the name on a provider_meta block is normalized correctly. Previously it appended diagnostics from that check but continued constructing the metadata object.

The patch retains those diagnostics and returns immediately when the name check contains errors. This prevents an invalid name from continuing into processing that assumes it has already passed validation. The release notes identify the previous outcome as a crash while loading such blocks.

The distinction between reporting an error and stopping invalid processing is useful here. Adding a diagnostic to a collection does not automatically prevent later code from using the rejected value. The decoder must also return a result that tells its caller no valid metadata object was produced.

An invalid configuration still fails after this release. The improvement is that the failure follows the validation path instead of continuing into a crash. This gives the user an actionable configuration error without requiring downstream processing to tolerate an object that should never have been constructed.

Generated keys need language-aware quoting

The configuration-generation patch in pull request 35837 replaces a whitespace test with HCL's identifier validation. Previously, generated map keys received quotes when they contained whitespace. That handled one invalid spelling but missed other keys that cannot be written as bare identifiers.

The tests add keys containing periods. A key such as key.with.periods must remain a single string key in generated configuration. Checking only for spaces is insufficient to preserve that meaning. The corrected condition asks whether the whole string is a valid HCL identifier, quoting it when it is not.

The intended shape can be illustrated without any provider-specific configuration.

locals {
  labels = {
    "service.example.com" = "frontend"
    ordinary_name        = "backend"
  }
}

The period-containing key is quoted, while the identifier-shaped key can remain unquoted. The example demonstrates the syntax distinction addressed by the generator. It does not claim these particular labels belong to a resource schema.

I consider this change relevant to importing existing infrastructure because generated configuration is still source code that must preserve the imported data's meaning. A map key supplied by a remote system need not resemble an HCL identifier. The generator must encode it under the language's rules.

State contributes provider requirements too

The provider validation change in pull request 35864 adds dependency checks against previous state during planning. State can still require a provider even when the current configuration no longer declares the corresponding resource. Checking configuration alone does not cover that case.

The added diagnostic identifies a provider required by state but unavailable to the planning context. For an installable provider it suggests initialization, while a missing built-in provider receives a version-specific explanation. The patch keeps those cases separate because initialization cannot install a provider that must be built into the executable.

These changes make failure messages reflect the operation's actual context. Registry installation retains the distinction between a package and its requested subdirectory. Metadata decoding stops after an invalid name, generated keys follow HCL syntax, and planning accounts for dependencies retained in state. Each gives the next stage information it can use without inferring a different failure from incomplete context.