Terraform fixes provider attachment when local names differ

A provider's local name can differ from the final component of its source address. Terraform 0.13 makes that distinction useful by giving providers explicit namespaced identities. Terraform 0.13.5 fixes a place where the implementation still assumed those two names matched.

The October 21 release describes the problem as incorrect attachment of provider configuration to the configured source address by local name. The patch in pull request 26567 shows the exact assumption. A transformer compared the configuration block's name directly with the provider address's type component.

I regard this as an important correction to the provider abstraction. A source address should establish which provider implementation a module needs. A module-local name should let that module refer to the implementation consistently, without requiring the name to duplicate a component of its global identity.

Resolving the local name before comparing configurations

The patch changes the attachment process to ask the module for LocalNameForProvider first. It then compares the provider configuration's name with that resolved local name, while retaining the alias comparison.

Before the change, a provider configuration using an arbitrary local name could fail to attach to the intended provider node. The source address still identified the implementation, but the matching step looked for the wrong name when finding its configuration.

The regression fixture makes that difference explicit. Its requirement gives the local name arbitrary to the source hashicorp/aws. Its provider block also uses arbitrary, and the resource explicitly selects that local provider name. The test supplies a mock provider schema with a required configuration attribute.

That mock is important when reading the example. The fixture's required attribute is part of the synthetic test schema. It should not be copied into a real AWS provider configuration as though it were a supported AWS setting.

The test validates the configuration and fails if diagnostics contain errors. Its purpose is to demonstrate that Terraform connects a correctly named configuration block to the provider even when the source's type component has another spelling. It isolates name resolution from real credentials or an external cloud API.

Local names and aliases have different jobs

A local name selects the provider within the module's requirement declarations. An alias distinguishes an additional configuration of that provider. The patch retains the alias check because resolving the provider implementation alone does not establish which configured instance the resource should use.

The 0.13 upgrade guide explains why explicit source addresses were introduced. They allow third-party namespaces and registries to identify providers without placing all implementations in one shared namespace.

The attachment fix completes a smaller internal obligation of that design. After Terraform resolves the source, it must still honor the module's chosen spelling when looking up configuration. A global identity cannot substitute for the module-local mapping.

This also explains why the failure is configuration-dependent. Many configurations use a conventional local name matching the source's type component. Those names satisfy the old assumption accidentally. A test that only used that naming convention would not demonstrate that the mapping worked in the general case.

A separate fix reduces repeated schema work

The versioned changelog also names a performance issue involving very large, deeply nested resource schemas. The implementation in pull request 26577 adds caching to decoder-specification generation.

A schema block can produce an HCL decoder specification. Repeating that construction for a large nested schema repeats work that does not change while the schema is in use. The patch records the generated specification and returns it on later requests for the same block.

The comments state an important assumption. Although the block structure is mutable in its representation, Terraform treats a schema as immutable for its lifetime. Mutating it while in use would be an error. The cache relies on that lifetime rule.

The cache lives outside the block structure because nested-block processing copies block values. Embedding synchronization state in copied values would not provide a safe shared cache. The external implementation instead uses a mutex to protect the stored specifications.

Cache cleanup follows schema lifetime

The patch keys entries by a numeric representation of the block's pointer and attaches a finalizer that removes the corresponding entry. Its comments explain that retaining specifications as blocks are recycled would otherwise keep growing the cache.

This is a more specific optimization than saying Terraform plans become faster. The change avoids regenerating decoder specifications for repeated use of the same schema block. The patch includes a benchmark fixture with nested schema branches, but it does not justify a universal speedup claim for every configuration.

I find both corrections useful examples of how infrastructure-tool maintenance depends on internal representations. The provider fix preserves an explicit naming relationship. The schema fix reuses information under a documented immutability assumption. Neither changes the desired infrastructure, but both affect Terraform's ability to interpret a configuration correctly and efficiently.

The practical scope of 0.13.5 is therefore identifiable from the sources. Modules with deliberately different provider local names exercise the repaired attachment path. Resources with large nested schemas can encounter the repeated decoder-generation work addressed by the cache. Each fix has a concrete trigger instead of a general claim about all provider behavior.