We were previously _trying_ to handle diagnostics here but were not quite
doing it right because we were testing whether the resulting error was
nil rather than appending it to the diagnostics and then seeing if the
result has errors.
The difference here is important because it allows DynamicExpand to return
warnings without associated errors when needed. Previously the graph
walker would treat a warnings-only result as if it were an error.
Ideally we'd change DynamicExpand to return diagnostics directly, but we
previously decided against that because there were so many implementors
to update, and my intent for this change is to be surgical in the update
so we minimize risk of backporting the change into patch releases.
When adding destroy edges between resources from different providers,
and a provider itself depends on the other provider's resources, we can
get cycles in the final dependency graph.
The problem is a little deeper than simply not connecting these nodes,
since the edges are still needed when doing a full destroy operation.
For now we can get by assuming the edges are required, and reverting
them only if they result in a cycle. This works because destroy edges
are the last edges added to managed resources during graph building.
This was rarely a problem before v1.3, because noop nodes were not added
to the apply graph, and unused values were aggressively pruned. In v1.3
however all nodes are kept in the graph so that postcondition blocks are
always evaluated during apply, increasing the chances of the cycles
appearing.
Because import uses the complete planning process, it must also call
RemovePlannedResourceInstanceObjects. This is required to serialized the
resulting state if there are data sources with an ObjectPlanned status
because they could not be read during the import process.
We may need to prune nodes from a full destroy plan graph which cannot
be evaluated if there is no current state.
Add missing method to nodeExpandPlannableResource to ensure planned
resource are handled correctly when pruning nodes.
Also add regression test coverage of the crash. This would occur when
objects with optional attributes had default values of different type
from the attribute type, and the objects were members of a collection.
For example:
list(object({
a = optional(set(string), [])
}))
If this type constraint is applied to a variable value where one object
has a set(string) value for a, and the other object applies the empty
tuple default, Terraform would crash.
The remote-state-data documentation page refers to the aws_s3_bucket_object resource and data which is deprecated. The documentation says to use aws_s3_object instead. This change updates the links for the S3 object solution for remote state.
Previously the cloud backend only supported the pre and post plan stages.
This commit adds support to display the output of the new pre-apply task
stage as well.
Previously all of the logic to retrieve Task Stages was in the backend_plan.go file.
This commit:
* Moves the logic to the backend_taskStages.go file.
* Replaces using an array to a map indexed by the Task Stage's stage. This makes it
easier to find the relevant stage in the list and means the getTaskStageIDByName
function is no longer required.
We've removed the main documentation pages for the backends that are
removed in Terraform v1.3, but we'll leave a small callout note so that
the backend names are still reachable through our search index once the
v1.3 docs are the active version.
The primary goal here is to help folks who have inherited configurations
using older versions of Terraform to learn about features they see in those
configurations, so the main thing here is the link to the older release
docs which include those. However, this is also a good opportunity to link
to the upgrade guide content which describes some possible migration
paths away from these removed backends.
Co-authored-by: Matthew Garrell <69917312+mgarrell777@users.noreply.github.com>
Co-authored-by: Laura Pacilio <83350965+laurapacilio@users.noreply.github.com>
Co-authored-by: Kevin Wang <kwangsan@gmail.com>
Co-authored-by: Judith Malnick <judith@hashicorp.com>
Co-authored-by: Martin Atkins <mart@degeneration.co.uk>
Co-authored-by: HashiBot <62622282+hashibot-web@users.noreply.github.com>
Applying object type defaults to null values can convert null to an
object with partial attributes. This means that even a specified default
value of null will not remain null after variable evaluation.
In turn, the result can then be invalid, if not all attributes in an
object type have defaults specified.
This commit skips the type default application step during config load
and variable evaluation if the default or given value is null of any
type. We still perform type conversion.
