Consider Converting List/Set Block Data With No Objects to Null List/Set

[bflad]

Module version

v1.0.1

Use-cases

Blocks in Terraform are considered structural meaning that they technically do not fit the definition of having a null value. When provider developers create a schema such as:

func (d ThingDataSource) Schema(ctx context.Context, req datasource.SchemaRequest, resp *datasource.SchemaResponse) {
	resp.Schema = schema.Schema{
		Blocks: map[string]schema.Block{
			"example": schema.SetNestedBlock{
				NestedObject: schema.NestedBlockObject{
					Attributes: map[string]schema.Attribute{
						"nested_example": schema.StringAttribute{
							Required:    true,
						},
					},
				},
			},
			/* ... */
		},
		/* ... */
	},
}

The set value will never itself be null, even with a configuration omitting the block wholly. This can be confusing for provider developers since attributes (nested or not) do not work the same way. Consider these situations for unconfigured blocks:

• Using a data model type and calling Get() will always return a known, empty collection value
• Calling GetAttribute() will always return a known, empty collection value
• Using configuration validators cannot just check the collection type IsNull() method without understanding the semantic difference with blocks. Instead, underlying elements (objects) would have to be checked for length.
• Similarly, using resource plan modifiers cannot just check the collection type IsNull() method

Ideally, working with attribute and block values that are unconfigured should be very similar in this particular case.

Proposal

The internal/fromproto* logic for data handling may be able to catch the scenario of a block collection type being empty and convert the collection type to null automatically. This would smooth over the differences between attribute data and block data in the framework while (theoretically?) not losing semantic accuracy. Given the framework is a higher level SDK, this automatic value translation should be an acceptable pragmatic exception to the general design preference of the framework to not introduce special behaviors on top of the provider protocol.

Terraform automatically will "fix" provider data that returns null collection types for blocks, so reverse handling for responses in internal/toproto* is not strictly necessary.

References

• fix invalid null blocks during refresh terraform#32424
• AtLeastOneOf and ConflictsWith validators on blocks indicate that the block is always configured terraform-plugin-framework-validators#91
• path: Valid Expressions for the Schema with No Matches Should Not Return Error #600

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.