0b2cc6298b
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. |
||
|---|---|---|
| .. | ||
| all_null.go | ||
| compatible.go | ||
| compatible_test.go | ||
| doc.go | ||
| lcs.go | ||
| lcs_test.go | ||
| objchange.go | ||
| objchange_test.go | ||
| plan_valid.go | ||
| plan_valid_test.go | ||