"GODEBUG" is a mechanism that the Go runtime forces on OpenTofu that allows
dynamic changes to various nuances of Go standard library behavior.
We cannot control when GODEBUG workarounds are added and removed from Go,
so if someone chooses to rely on them then they are likely to get broken
by a later release of OpenTofu that uses a newer version of Go. Therefore
we'd like anyone relying on these to tell us so we can try to find a more
sustainable solution to their problem early on while the workaround is
still available to them.
We also occasionally force certain GODEBUG workarounds on by default in our
official builds in anticipation of breakage caused by upstream Go changes.
In that case we'd still like to know if anyone is relying on them so that
we can remove those workarounds in a future release, but we'd prefer to
get the reports about it in an issue or discussion we'd already created
for that purpose.
This therefore introduces warning diagnostics any time something in the
"init", "plan", or "apply" commands relies on non-default GODEBUG settings.
For ones we enabled intentionally we provide a specific URL to report usage
as part of the diagnostic message, but we also have a generic message for
any GODEBUG settings the user chose to enable for themselves for reasons
we probably don't know about yet but would like to learn more about.
This is included in only that subset of commands as a compromise because
those are the commands most likely to interact with Go library features
that are affected by these workarounds -- they most commonly affect
functionality related to networking, TLS, etc -- and additional diagnostics
in these locations should not to cause breakage for anyone consuming the
machine-readable output, but there are other commands where additional
diagnostics are more likely to cause problems.
Unfortunately it isn't really possible to unit-test this because it relies
directly on information reported by the Go metrics system and there's no
facility to produce fake metrics for testing. However, Go 1.26 (which we're
currently using) there is a GODEBUG setting "netedns0=0" which causes a
warning any time OpenTofu makes a DNS request, so I've tested this manually
by running "tofu init" with that workaround enabled in a configuration that
depends on at least one provider (causing DNS lookups for the provider
registry) and seen it generate the expected warning message referring to
"netedns0".
These new warnings replace our previous quieter messages about this in
the TF_LOG=warn output, because those were only useful in situations where
GODEBUG was causing a problem that led to someone opening a bug report, but
we actually want to know of situations where GODEBUG was needed in order
for OpenTofu to _succeed_ and so for that we need more prominent messages
to let the operator know there's something they ought to report to us even
though there wasn't an error.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The "terraform_version" property of the JSON state format (intentionally
misnamed for backward-compatibility with our predecessor) changes each time
we make a new release, so we'll compare it with the currently-expected
version number instead of with a hard-coded value.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
On Windows, the two sequential plan runs in TestJsonIntoStream have different latencies — the -json-into run is consistently slower and crosses the timer threshold that emits state_lock_acquire, while the -json run does not. This causes a spurious one-line diff between the two outputs.
Strip state_lock_acquire/release lines from both outputs before comparison since these messages are timing-dependent and not relevant to the test's core assertion.
Previously we interpreted a "required_version" argument in a "terraform"
block as if it were specifying an OpenTofu version constraint, when in
reality most modules use this to represent a version constraint for
OpenTofu's predecessor instead.
The primary effect of this commit is to introduce a new top-level block
type called "language" which describes language and implementation
compatibility metadata in a way that intentionally differs from what's used
by OpenTofu's predecessor.
This also causes OpenTofu to ignore the required_version argument unless
it appears in an OpenTofu-specific file with a ".tofu" suffix, and makes
OpenTofu completely ignore the language edition and experimental feature
opt-in options from OpenTofu's predecessor on the assumption that those
could continue to evolve independently of changes in OpenTofu.
We retain support for using required_versions in .tofu files as a bridge
solution for modules that need to remain compatible with OpenTofu versions
prior to v1.12. Module authors should keep following the strategy of
having both a versions.tf and a versions.tofu file for now, and wait until
the OpenTofu v1.11 series is end-of-life before adopting the new "language"
block type.
I also took this opportunity to simplify how we handle these parts of the
configuration, since the OpenTofu project has no immediate plans to use
either multiple language editions or language experiments and so for now
we can reduce our handling of those language features to just enough that
we'd return reasonable error messages if today's OpenTofu is exposed to
a module that was written for a newer version of OpenTofu that extends
these language features. The cross-cutting plumbing for representing the
active experiments for a module is still present so that we can reactivate
it later if we need to, but for now that set will always be empty.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
We don't typically just broadly run automatic rewriting tools like "go fix"
across our codebase because that tends to cause annoying and unnecessary
merge conflicts when we're backporting to earlier release branches.
But all of the files in this commit were changed in some non-trivial way
already during the OpenTofu v1.11 development period anyway, and so the
likelyhood we'd be able to successfully backport from them is reduced and
therefore this seems like a good opportunity to do some focused
modernization using "go fix".
My rules for what to include or not are admittedly quite "vibes-based", but
the general idea was:
- Focusing on files under the "command" directory only, because that's
already been an area of intentional refactoring during this development
period.
- If the existing diff in a file is already significantly larger than
the changes the fixer proposed to make, or if the fixer is proposing
to change a line that was already changed in this development period.
- More willing to include "_test.go" files than non-test files, even if
they hadn't changed as much already, just because backports from test
files for bug fixes tend to be entirely new test cases more than they
are modifications to existing test cases, and so the risk of conflicts
is lower there.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
