Implicit move statement for modules previously using `count` and
then moving to use `enabled`, or vice versa.
Signed-off-by: Diogenes Fernandes <diofeher@gmail.com>
Some of our test cases expect that planning will fail but will still return
a non-nil plan with Errored set to true, and some other cases were not
expecting plan to fail at all, and in all of those cases a failure to meet
that expectation caused a panic rather than a test failure.
When debugging a problem that affects many tests it's annoying when the
test run panics partway through, so these small changes make these tests
a little more resilient to the system not behaving in the way they were
expecting, without affecting the behavior when the system behaves as
expected.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
It seems that a small number of providers are now able to return a special
signal when they find that they are unable to perform an operation due to
unknown values in the provider or resource configuration.
This is a uses that new signal to recommend a workaround in that situation,
giving a more actionable error message than would've been returned by the
provider otherwise.
We've not yet decided how OpenTofu might make use of these new signals in
the long term, and so this is intentionally implemented in a way where
most of the logic is centralized in the provider-related packages rather
than sprawled all over "package tofu".
It's likely that a future incarnation of this will plumb this idea in more
deeply, but this is just a temporary stop-gap to give slightly better
error messages in the meantime and so it's better to keep it relatively
contained for now until we have a longer-term plan for what OpenTofu Core
might do with this information.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Resolves#2532
The refactoring involves a few decisions:
When returning invalid values, we return the original value wrapped on NullVal. Before we were just returning cty.NullVal(cty.Map(cty.DynamicPseudoType)) for everything.
When returning unknown values, we wrap it on UnknownVal. Previously we had a lot of different behaviors depending on the code path.
I decided to do that so we maintain a context of the types, without losing them when returning it to something that doesn't mean anything.
Signed-off-by: Diogenes Fernandes <diofeher@opentofu.org>
Signed-off-by: Christian Mesh <christianmesh1@gmail.com>
Co-authored-by: Christian Mesh <christianmesh1@gmail.com>
This continues our ongoing effort to get a coherent chain of
context.Context all the way from "package main" to all of our calls to
external components.
Context.Apply does not yet do anything with its new context, but this gets
the context plumbed in enough that we should be able to pass values like
telemetry spans all the way from the top-level in future.
OpenTofu has some historical situational private uses of context.Context
to handle the graceful shutdown behaviors. Those use context.Context as
a private implementation detail rather than public API, and so this commit
leaves them as-is and adds a new "primary context" alongside. Hopefully
in future refactoring we can simplify this to use the primary context also
as the primary cancellation signal, but that's too risky a change to bundle
in with this otherwise-mostly-harmless context plumbing.
All of the _test.go file updates here are purely mechanical additions of
the extra argument. No test is materially modified by this change, which
is intentional to get some assurance that isn't a breaking change.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This continues our ongoing effort to get a coherent chain of
context.Context all the way from "package main" to all of our calls to
external components.
Context.Plan does not yet do anything with its new context, but this gets
the context plumbed in enough that we should be able to pass values like
telemetry spans all the way from the top-level in future.
OpenTofu has some historical situational private uses of context.Context
to handle the graceful shutdown behaviors. Those use context.Context as
a private implementation detail rather than public API, and so this commit
leaves them as-is and adds a new "primary context" alongside. Hopefully
in future refactoring we can simplify this to use the primary context also
as the primary cancellation signal, but that's too risky a change to bundle
in with this otherwise-mostly-harmless context plumbing.
All of the _test.go file updates here are purely mechanical additions of
the extra argument. No test is materially modified by this change, which
is intentional to get some assurance that isn't a breaking change.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
