Terraform 1.8.4 avoids repeated dependency graph walks

Several resources can depend on the same infrastructure without requiring the planner to rediscover that infrastructure for each relationship. Terraform 1.8.4 fixes a case where broad module dependencies did cause repeated discovery. The release addresses an exponential slowdown in some graphs using module-level depends_on, with a change to how the implementation gathers transitive dependencies.

The 1.8.4 release, published on 22 May, also repairs configuration generation for nested optional and computed id attributes. The fixes concern different operations, but both become clearer when examined below the configuration syntax. One changes the scope of a graph traversal. The other changes how a schema filter identifies the attribute it should remove.

I value Terraform's reusable modules because they can express infrastructure relationships across provider APIs. A slowdown in processing those relationships directly affects the usefulness of that abstraction. The interesting part of this patch is that it retains the declared dependencies while reducing repeated work in finding them.

Shared ancestors were revisited

The dependency fix in pull request 35157 explains the problematic graph shape. A module-level depends_on can connect many nodes to the same dependencies. When Terraform searches the ancestors of each dependency separately, those searches can repeatedly encounter the same transitive ancestors.

The pull request attributes the resulting processing-time and memory growth to redundant traversal. That diagnosis matters because it distinguishes planner overhead from slow remote APIs. Increasing the capacity of an infrastructure service would not remove repeated work inside the dependency graph. The correction belongs in the implementation that interprets the configuration.

Previously, the relevant code called Ancestors separately for each dependency and appended the resources found by each call. The patch changes the graph helper to accept several starting vertices. It forms a set containing their outgoing dependencies, then runs a depth-first walk from that combined starting set. Set membership removes duplicate starting points.

The caller changes accordingly. It collects directly dependable resources, then requests ancestors for all dependencies in one operation. Shared ancestry can be considered by a common traversal instead of repeatedly through individual calls. This is a change to the work needed to compute dependencies, not permission to omit a dependency declared by the user.

The patch also generalizes the reverse traversal helper, Descendents, to accept multiple vertices. The central caller change shown in this fix concerns finding parent-module dependencies. It is useful to keep those details separate, because a more general helper does not imply that every possible graph operation was the reported bottleneck.

A broad dependency declaration can still represent a broad relationship. This release does not promise that module-level ordering has the same granularity as referring to one particular resource attribute. Its documented benefit is eliminating redundant traversal for affected graphs. That is a more specific and useful claim than saying every plan becomes faster.

An identifier needs its schema location

The configuration-generation fix in pull request 35220 starts with a compatibility workaround. The legacy provider SDK adds an id attribute at the root of resource schemas. Terraform filters that attribute out when generating configuration because emitting it can produce invalid configuration for those resources.

The previous filter identified the attribute by its name and its optional/computed flags. That was too broad. A nested attribute called id can be a legitimate part of the provider's schema, with different meaning from the legacy root identifier. Applying the root-level workaround recursively removed nested information it was meant to preserve.

The patch replaces name-only filtering with a path-aware operation. Its condition compares the attribute's path against the root id path, while retaining the optional and computed checks. The recursive schema walk carries the current path into nested objects and blocks. Identically named attributes can therefore receive different treatment based on their location.

The regression test makes this distinction concrete. It defines a resource with a nested list containing an optional, computed id. Importing that resource and requesting generated configuration must complete without errors. The test does not merely assert that a root identifier disappears. It verifies that the workaround no longer prevents configuration generation for a valid nested schema.

As a provider author, I find this correction particularly relevant. Attribute names acquire meaning within a schema, and a common name does not establish a universal role. A core compatibility filter needs enough context to distinguish SDK bookkeeping from a field that a provider deliberately exposes to users.

Why these implementation details matter

These fixes preserve information at different stages of Terraform's work. Dependency discovery should retain the relationship while avoiding duplicate computation. Configuration generation should retain a legitimate nested attribute while excluding the specific root attribute covered by the SDK workaround. Neither task can be judged by the short spelling of the configuration alone.

The practical audience for the graph fix is configurations with the affected overlapping module dependencies. The import fix concerns resources whose schemas contain the nested optional/computed identifier shape. Version 1.8.4 supplies both corrections in the CLI, so their applicability follows the configuration and schema being processed.

The release notes also list an update to golang.org/x/net addressing CVE-2023-45288. That is a separate dependency maintenance item, not evidence that the graph slowdown itself was a security vulnerability. The graph and import patches give direct explanations for the two configuration-processing failures addressed here, including the exact traversal and schema context each operation needed.