Nested object attributes are instantiated during plan when config is null

[jbardin]

With a nested map or list attribute, if a null value is passed in from the configuration, the framework always returns a non-null object. Even for computed attributes this is technically not valid, because the "Computed" concept applies to the parent attribute (nested_map below), not the individual items. For non-computed attributes this is also not valid, but Terraform core cannot catch this validation and will let it pass through (upon resolution of hashicorp/terraform#35083)

Example schema containing a MapNestedAttribute (ListNestedAttribute works similarly):

Attributes: map[string]schema.Attribute{
	"nested_map": schema.MapNestedAttribute{
		NestedObject: schema.NestedAttributeObject{
			Attributes: map[string]schema.Attribute{
				"map": schema.MapAttribute{
					ElementType: types.StringType,
					Optional:    true,
				},
				"string": schema.StringAttribute{
					Optional: true,
				},
			},
		},
		Optional: true,
	},
},

With the given configuration:

resource "examplecloud_thing" x {
  nested_map = {
    key1 = {
      map = {}
      string = "test"
    }
    key2 = null
  }
}

The resulting plan looks like:

  # examplecloud_thing.x will be created
  + resource "examplecloud_thing" "x" {
      + nested_map = {
          + "key1" = {
              + map  = {}
              + string = "test"
            },
          + "key2" = {},
        }
    }

With the key2 value changing from null to an object with null attributes.

[bflad]

Hey @jbardin 👋 I think I see what is happening deep inside the framework server's plan modification handling -- when it is handling a map nested attribute, it is always assuming that the "object" that makes up the map value is always a known object with all its attributes. I am kind of surprised we have not yet seen a bug report about this. If in the unit testing I try to intentionally inject a null object value there, it actually panics. It makes me wonder if Terraform is actually sending over the known object with nulls since a null object panics (I can separately try to verify this with protocol data), but in any event I think we just need to add some additional null/unknown checks to immediately roundtrip the null/unknown back. If that's not the case, will post another update here.

[jbardin]

Thanks @bflad, I didn't check to see if this was somehow getting encoded as an object with nulls rather than a null object coming from core, but that's possible too. Even better, if we can determine that this could never work in any form I can extend the validation to reject these plans entirely, but that's harder to prove.

[jbardin]

The value from core looks correct, I see "key2":cty.NullVal(... being encoded for PlanResourceChange

[bflad]

Okay thanks!

[bflad]

The framework was errantly converting those null/unknown objects into known objects by always running plan modification on the nested attributes. #995 will now skip that automatic behavior (instead roundtripping the null/unknown object) unless overridden by the provider developer.