Terraform 1.14.8 tolerates stale attribute paths in plan display
A provider schema change could leave relevant attribute paths inconsistent with the values a plan renderer encountered. Terraform 1.14.8 treats those mismatches as unmatched paths.
Terraform 1.14.8, released on March 25, fixes a crash when displaying relevant attributes after provider upgrades. The release notes describe a rendering failure. That scope matters. The repair concerns how Terraform presents information to the reviewer, and does not establish that every provider upgrade produces a valid or desirable infrastructure change.
I value Terraform's reusable abstraction over infrastructure APIs, and use it both as a configuration author and a provider author. The plan is where I expect that abstraction to explain a proposed change. A renderer that crashes before it can identify the affected resource removes information I need to decide what to investigate. This patch makes a specific part of that presentation more tolerant of references that no longer fit the data.
Paths can outlive the structure they describe
The explanation in pull request 38264 identifies an assumption in PathMatcher. Its callers were expected to know whether the next part of a path referred to a list index or an object key. That expectation is reasonable when the path and the value come from the same known structure. It becomes unsafe when a reference was derived under different assumptions.
Terraform derives RelevantAttributes from references to an object. The pull request describes two ways those paths can fail to correspond to the value being rendered. An expression can contain an error hidden by try or can. A provider schema upgrade can also change the target resource's structure. In either case, the renderer cannot assume that an existing path proves the type of the next value it encounters.
This is a distinction between a reference and the current data. An object key and a list index are both steps in a path, but they require different traversal operations. When the structure changes, applying the old kind of step to the new value can fail even if the renderer has useful information elsewhere. The patch stops treating the mismatch as sufficient reason to abort the display.
The author describes this use of relevant attributes as a best-effort display of relevant differences caused by changes outside Terraform. It is not an appropriate stage to diagnose every invalid attribute path. If that display panics, the user may lack the resource information needed to work around the problem. Keeping the display available preserves the opportunity to inspect the actual changes.
The matcher now rejects mismatches without crashing
The code change replaces an unconditional string type assertion in GetChildWithKey with a type switch. A string can still match the requested key. A numeric path component, represented there as float64, does not match an object key. That case now leaves the child matcher without a matching path instead of causing the assertion to panic.
Traversal by index also changes. When a path component is a string, the matcher attempts to parse it as a number. Previously, an unsuccessful parse caused a panic. The corrected condition only adds a matching child path when parsing succeeds and the index matches. A string that cannot represent the requested index therefore produces no match.
This tolerance is specific. The implementation still contains panic handling for unexpected component types outside those cases. I would not describe the patch as making arbitrary malformed paths acceptable. It handles mismatches between the supported key and index representations that can arise when references and the current structure disagree.
The regression test exercises both directions. It asks for a key when the path starts with a numeric index, and later asks for a key where another numeric step remains. Those lookups must produce neither an exact match nor a partial match. The test also verifies that valid traversal through the intervening index and key still retains a partial match.
A readable plan still requires review
The original report includes a panic about converting an interface value from float64 to string. Its stack reaches the attribute path matcher through the structured diff renderer and human plan rendering. That gives the release note a concrete failure location. It does not justify attributing every problem in the reporter's configuration to the same cause.
For an affected configuration, the next check after upgrading the Terraform executable is the operation that previously failed:
terraform plan
I would examine the resulting plan with the provider upgrade still in mind. The matcher can now decline a stale relevance path, but the patch does not prove that a changed schema preserves the intended resource behavior. A successful display gives the reviewer access to information that the crash previously prevented them from seeing.
This also suggests a useful boundary for provider upgrade checks. I want validation of the provider's state handling and configuration compatibility, and I want the command that presents the result to complete. Those checks examine different behavior. Terraform 1.14.8 repairs a failure in the second part, where an assumption about attribute paths prevented the review from reaching the infrastructure changes at all.