17 Commits (5848d8a2b4e0c500c384bcbdcc84b5feec3f6549)

Author	SHA1	Message	Date
hashicorp-copywrite[bot]	53c34ff49c	Update copyright file headers to BUSL-1.1	3 years ago
Martin Atkins	d49e991c3c	plans/objchange: Support nested unknowns in our unrefinedValue shim ... Several parts of the objchange logic incorrectly use cty.Value.RawEquals for value comparison, instead of more appropriate comparison methods like cty.Value.Equals or c.Value.Range().Includes. That makes them incorrectly consider two unknown values with the same type but different refinements as always non-equal, rather than evaluating based on the overlap between the refinements (if any). As a short-term fix for that we previously added this unrefinedValue shim that just strips away the refinements for comparison, thus allowing callers to continue using RawEquals as long as they've already taken care of all of the other things that can make that go wrong, such as value marks. Unfortunately the shim was too simplistic and only supported direct unknown values. Unknown values with refinements can also appear nested inside known container values such as collections, so the shim needs to recursively un-refine the entire data structure in that case. This is still intended only as a temporary fix until we have time to revisit all of the callers and make them use cty's own logic for comparison. Using cty's own logic will make the results more precise, because e.g. it can notice if two unknown strings have different known prefixes and therefore cannot possibly be equal despite not being fully known. For now this shim will accept any pair of unknown values of the same type as equal, regardless of refinement.	3 years ago
James Bardin	f6c536e436	validate planned set sizes using refinements	3 years ago
James Bardin	3c8a163583	set length is unknown with partially known elems ... If a set contains partially known values the length is unknown which causes assertPlannedObjectValid to fail valid plans. Revert to the old method if using LengthInt for the set lengths, which returns the maximum number of possible elements, with a guard for entirely unknown set values.	3 years ago
Martin Atkins	4c439b099f	plans/objchange: Don't consider refinements when validating plans ... Providers that existed prior to refinements (all of them, at the time of writing) cannot preserve refinements sent in unknown values in the configuration, and even if one day providers _are_ aware of refinements there we might add new ones that existing providers don't know how to handle. For that reason we'll absolve providers of the responsibility of preserving refinements from config into plan by fixing some cases where we were incorrectly using RawEquals to compare values; that function isn't appropriate for comparing values that might be unknown. However, to avoid a disruptive change right now this initial fix just strips off the refinements before comparing. Ideally this should be using Value.Equals and handling unknown values more explicitly, but we'll save that for a possible later improvement. This does not include a similar exception for validating whether a final value conforms to a plan because the plan value and the final value are both produced by the same provider and so providers ought to be able to be consistent with their _own_ treatment of refinements, if any. Configuration is special because Terraform itself generates that, and so it can potentially contain refinements that a particular provider has no awareness of.	3 years ago
James Bardin	2f308cf948	Merge pull request #32962 from hashicorp/jbardin/validate-unknown-coll-attrs ... validate unknown nested attribute collections	3 years ago
hashicorp-copywrite[bot]	325d18262e	[COMPLIANCE] Add Copyright and License Headers	3 years ago
James Bardin	8ab7af8c5f	validate unknown nested attribute collections ... It is not valid for a provider to return an unknown value for a configured nested collection, but we need to check for unknowns before comparing the number of values in the collection.	3 years ago
James Bardin	ea193d5ce6	don't panic with a null list block value in config ... Using ignore_changes with a list block, where the provider returned an invalid null value for that block, can result in a panic when validating the plan. Future releases may prevent providers from storing a null block in state, however we can avoid the panic for now. Only the NestingList case needs to be handled, because legacy providers only have list and set blocks, and the set case does not use the config value.	3 years ago
James Bardin	a6a08fe84a	AssertPlanValid for computed with config value ... Return early from AssertPlanValid for any attribute which is only computed. We currently fail if there's a config value, but that could only happen because of core, not because of the provider.	4 years ago
James Bardin	782132da33	remove incorrect computed check ... The config is already validated, and does not need to be checked in AssertPlanValid. Add some more coverage for plan validation.	5 years ago
James Bardin	f195ce7fd4	remove temp test	5 years ago
James Bardin	ea68d79ea2	nested object values can be computed ... While blocks were not allowed to be computed by the provider, nested objects can be. Remove the errors regarding blocks and verify unknown values are valid.	5 years ago
James Bardin	903797084a	objects vs maps in nested object types ... When using NestedMap objects, unify the codepath for both maps and objects as they may be interchangeable.	5 years ago
James Bardin	7ca6be8285	correctly verify planned nested object values ... The validation for nested object types with computed attributes was using the incorrect function call.	5 years ago
James Bardin	b7f8ef4dc6	handle unexpected changes to unknown block ... An unknown block represents a dynamic configuration block with an unknown for_each value. We were not catching the case where a provider modified this value unexpectedly, which would crash with block of type NestingList blocks where the config value has no length for comparison.	5 years ago
Martin Atkins	034e944070	Move plans/ to internal/plans/ ... This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.	5 years ago