Terraform 1.7.4 repairs test paths and numeric plan output

A test suite can load successfully while using the wrong inputs. Terraform 1.7.4 fixes that possibility on Windows, where a path comparison prevented the test framework from adding variables supplied in the testing directory. Its other fix concerns the human-readable plan, where conversion through a floating-point representation could change a large number before displaying it. Both defects affect information engineers rely on when deciding whether configuration behaves as intended.

The 1.7.4 release notes, dated 21 February, list these two corrections. The small release is easier to understand through the patches themselves. Neither requires a new language construct. Each corrects an implementation choice that changed the meaning of information passing between parts of the tool.

I reach for Terraform because reusable configuration can express a substantial infrastructure contract. That makes the input and review paths consequential. A correct resource implementation is insufficient if a test silently chooses different variables or a reviewer sees a numeric value different from the one represented in the plan.

How a path comparison dropped variables

The Windows test fix in pull request 34666 replaces Go's path package with path/filepath in the local test runner. The important comparison occurs while initializing variables for a test file. Terraform checks whether the directory containing that file equals the suite's testing directory. When it does, the runner includes variables loaded from that directory's default variable files.

Before the correction, the runner used path.Dir(file.Name) for that comparison. The patch changes it to filepath.Dir(file.Name). The pull request explains that the previous package selection caused loading and processing of automated test-directory variable files to fail on Windows. A filesystem path needs the platform-aware interpretation supplied by filepath.

This distinction can be obscured by tests that exercise only one operating system. A slash-separated path works with the old operation, so the directory equality check can appear reasonable during development. The defect becomes visible when the actual filename representation follows Windows conventions. A comparison intended to establish directory membership then fails, and the code does not add that directory's variables.

The patch is narrow enough to explain the symptom without speculating about provider behavior. The branch that includes test-directory variables was conditional on directory equality. An incorrect result at that branch changes the variable environment available to the run. Nothing in the fix suggests that a provider rejected an otherwise correct input or that configuration parsing needed a language change.

The tagged changelog supplies the history. Terraform 1.7 added automatic loading of terraform.tfvars in the testing directory for tests in that directory. Version 1.7.4 makes the Windows implementation match that intended behavior. Moving every variable into a test block might conceal the problem, but it would also change how the suite organizes shared inputs.

The same pull request replaces path.Join with filepath.Join in two diagnostic messages. Those changes concern the names printed when verbose output cannot be rendered. They accompany the functional directory comparison fix, but they should not be confused with its cause. The variable inclusion decision is the part that changes the test environment.

Numeric text should survive the renderer

The numeric rendering correction in pull request 34702 changes how the JSON plan is decoded and how primitive numeric values are rendered. The pull request describes numbers larger than 2^63 being truncated in human-readable output. Its implementation replaces a float64 representation with json.Number so rendering can retain the original numeric text.

Previously, the primitive renderer constructed a big.Float from a value that had already become float64, then formatted that result. A larger output representation cannot recover information lost during an earlier conversion. The patch instead reads a json.Number and calls its String method. That removes the intermediate floating-point conversion from this display operation.

The regression tests include the numeric text 9223372036854773256 and expect the same digits in the rendered result. They also check decimal values such as 1.23456789. These cases help define the fix more precisely than an informal description of large integers. The objective is to preserve a number through the display pipeline, including representations that the old conversion could alter.

A configuration can expose a large numeric output without any remote provider, for example the following expression.

output "large_numeric_value" {
  value = 9223372036854773256
}

The number matches the regression case in the patch. This example concerns the renderer's handling of a numeric value. It does not establish that every downstream provider or API accepts arbitrarily large integers. Those systems retain their own type and range requirements.

I consider plan rendering part of Terraform's correctness contract because the plan is the material a person reviews before allowing changes. A display fix does not imply that earlier applies necessarily sent the displayed, altered number to an API. The release identifies a human-readable rendering defect, and that distinction matters when interpreting an existing plan or investigating a discrepancy.

The two patches also illustrate different ways an implementation can lose meaning. The test runner selected the wrong variable environment because it interpreted a path with the wrong conventions. Meanwhile, numeric rendering selected a representation that could not retain the information it needed to print. Terraform 1.7.4 corrects the selection at each boundary, so tests receive the intended directory inputs and numeric plan output retains its supplied digits.