10 Commits (1242e084733e55cc9d4e8a90c5ee518682ba3a67)

Author	SHA1	Message	Date
Martin Atkins	0b2cc6298b	plans/objchange: Fix panic in AssertObjectCompatible with set blocks ... Our usual "ground rules" for mapping configschema to cty call for the collection values representing nested block types to always be known and non-null, using an empty collection to represent the absense of any blocks of that type so that users can always safely use length(...) etc on them without worrying about them sometimes being null. However, due to some different behaviors in the legacy SDK we've allowed it an exception to this rule which means that we can see unknown and null collections in these positions in object values returned from provider operations like PlanResourceChange and ApplyResourceChange when the legacy SDK opt-out is activated. As a consequence of this, we need to be mindful in our safety check functions, like AssertObjectCompatible here, of tolerating these non-ideal situations to allow the safety checks to complete. We run these checks even when the provider requests an opt-out, because we want to note any inconsistencies as WARNING level log lines to aid in debugging.	7 years ago
Martin Atkins	e831182c8d	plans/objchange: Hide sensitive attribute values in error messages ... Since these error messages get printed in Terraform's output and we encourage users to share them as part of bug reports, we should avoid including sensitive information in them to reduce the risk of accidental exposure.	7 years ago
Martin Atkins	7216049fdb	plans/objchange: Improve precision of AssertObjectCompatible with sets ... Previously we were just asserting that the number of elements didn't grow between planned and actual. We still can't precisely correlate elements in sets with unknown values, but here we adapt some logic we added earlier to config/hcl2shim to ensure that we can find a plausible correlation for each element in each set to at least one element in the other set, and thus catch more cases where set elements might vanish or appear between plan and apply, for improved safety. This will still generate false negatives in some cases where unknown values are present due to having to assume correlation is intended wherever it is possible, but we'll catch situations where the actual value is obviously contrary to what was planned.	7 years ago
James Bardin	78256ae225	return early when comparing Null values	8 years ago
James Bardin	e93d69f18b	more nil/known checks before val.LengthInt	8 years ago
James Bardin	e08a388d3c	check IsKnown on values that may panic	8 years ago
Martin Atkins	32974549cd	plans/objchange: Fix handling of unknown in AssertValueCompatible ... We need to check for the known-ness of the prior value before we check for the null-ness of actual, because it's valid for an unknown value to become a null.	8 years ago
Martin Atkins	8048e9a585	plans/objchange: Don't panic if old or new values are null	8 years ago
Martin Atkins	549544f201	configschema: Handle nested blocks containing dynamic-typed attributes ... We need to make the collection itself be a tuple or object rather than list or map in this case, since otherwise all of the elements of the collection are constrained to be of the same type and that isn't the intent of a provider indicating that it accepts any type.	8 years ago
Martin Atkins	4c78539c2b	plans/objchange: AssertObjectSuperset function ... This function's goal is to ensure that the "final" plan value produced by a provider during the apply step is always consistent with the known parts of the planned value produced during the plan step. Any error produced here indicates a bug in the provider.	8 years ago