Terraform 1.15.7 serializes shared parser access

Terraform 1.15.7, released on June 24, adds concurrency safety to configs.Parser and SourceBundleParser. Its release notes also include a correction to submodule variable validation during initialization. These changes concern configuration loading, before an operator can review a useful infrastructure plan. Neither introduces syntax that a configuration author needs to adopt to receive the fix.

Terraform is a daily driver for me, including work as a provider author. I value the separation between a reusable configuration language and the APIs its providers implement. Configuration loading has to support that separation reliably. A parser race can prevent the configuration from reaching the point where provider behavior is relevant, while an initialization error can stop the workflow before its intended validation stage.

A source cache is shared mutable state

The parser patch adds a mutex to each parser type. In configs.Parser, it protects operations that load HCL files, retrieve sources, and force a source file into the parser cache. It also protects access to the flag that controls whether language experiments are allowed. Several callers switch from directly reading that flag to using the synchronized accessor.

The author explains that protecting source access was sufficient for the reported problem, then extends the correction to related methods and the source bundle parser. That scope is useful to understand. The release is not claiming a new parallel parsing algorithm. It establishes synchronization around state that concurrent callers could otherwise access without the necessary coordination.

I would read the mutex as a correctness choice. Calls that need the same parser lock must wait for each other while those protected methods execute. That can constrain concurrency on a shared parser instance. The patch supplies no benchmark that would justify a throughput claim, and I would not infer one from the addition of locking.

The source bundle parser receives protection around configuration file loading and experiment flag access as well. In its locked loading method, the code can read the flag directly because the method already holds the mutex. Other callers use synchronized access. This is a concrete example of why adding a lock requires checking the paths that reach the data, not merely declaring a mutex beside the field.

The tests exercise overlapping operations

One new regression test repeatedly asks the loader for its sources while another goroutine forces file sources into the parser. A shared start signal lets those operations overlap. The file is restricted to race-enabled test builds. This is a useful test of the reported condition because source retrieval and cache mutation act on the same underlying parser state.

A second race-enabled test has multiple workers load configuration through the same source bundle parser. It constructs a local bundle and configuration files for the test. That keeps the concurrency exercise focused on parser use, without requiring a remote module service to reproduce the overlap.

The test structure matters more than simply running a normal configuration twice. Sequential calls would not exercise the same access pattern. A concurrency regression test needs competing operations that reach the shared state. These tests supply that overlap and let the race-enabled build examine it.

For operators, the appropriate upgrade check remains the workflow that encountered the problem. The patch does not require changing module syntax to avoid shared parser access. I would keep the Terraform executable version visible in that check so a successful retry can be associated with the corrected implementation, while preserving the configuration needed to reproduce the original failure.

Initialization requires only the inputs it needs

The submodule validation fix addresses a different assumption. Its author describes a regression in the 1.15 series. Initialization was treating missing required child module variables as blockers even when those variables were not needed to determine a module source. Later validation or planning remains responsible for reporting an incomplete ordinary module call.

The code now records that the variable transformer is executing an initialization operation. While building its schema for that operation, it only makes a missing input required when the variable is constant. This preserves the need to obtain initialization-time values without demanding every later input before initialization can complete.

The added tests distinguish an ordinary missing string input from a missing constant input used as a nested module source. In the first case, initialization can finish loading its module. The second still expects a missing-required-argument diagnostic. That difference explains the repair more accurately than describing it as a general relaxation of variable validation.

I would check an affected configuration with separate commands:

terraform init
terraform validate

Successful initialization does not establish that all required inputs are present. The correction lets initialization complete when it has the information necessary for its own work. Validation can then report configuration problems at the appropriate stage. For a reusable module, I want tests that preserve both outcomes, so an initialization repair does not accidentally become permission for an incomplete configuration to pass later checks.