Add "optional attribute" support for types.Object

[jason-johnson]

Module version

v1.6.1

Relevant provider source code

function.ObjectParameter{
				Name:           "args",
				Description:    "Extra variables for use in format.",
				AllowNullValue: true,
				AttributeTypes: map[string]attr.Type{
					"location":    types.StringType,
					"extra_tokens": types.MapType{ElemType: types.StringType},
				},
			},

Terraform Configuration Files

provider::namep::custom_name("test", "azurerm_resource_group", { location = "westeurope" })

Expected Behavior

extra_tokens should be null since it wasn't passed

Actual Behavior

The function call fails and forces the user to explicitly pass extra_tokens = null

Steps to Reproduce

Create a provider function
Have at least one parameter be an ObjectParameter
Try to call the function without explicitly passing every argument

[austinvalle]

Hey there @jason-johnson 👋🏻 , thanks for reporting this and sorry you're running into this issue.

I'm able to verify the bug, but I wanted to add that there will also likely need to be some design decisions and enhancements made here by the maintainers to fully enable this behavior.

Before functions, all object implementations had accompanying schema information available to determine which object properties are allowed to be null. Since functions don't have a similar concept to configurability, we'll likely need to expose some method of defining optional attributes for an object, i.e. an object type constraint.

Not an ideal workaround, but when #931 is merged and released, provider developers will be able to define a DynamicParameter, which will be dynamically typed, equivalent to the any constraint. This would allow a provider function to accept any object type (unfortunately, also every other type), and validate manually it has the required information to run the function.

[austinvalle]

I've adjusted the title to match what we can do to resolve this request. Luckily, all the changes we should have to make are local to terraform-plugin-framework, as OptionalAttributes are already supported in tftypes: https://github.com/hashicorp/terraform-plugin-go/blob/c4db80ae89de84e264c3b8c4ccac9e6d5132390d/tftypes/object.go#L25-L43

[c-baumgartner]

I am working on a function-only provider and need to pass a config object as parameter. Within the ObjectAttribute definition most (actually all 😄 ) attributes are optional. Currently I have to craft a full definition the object with null-values and pass it to the function call. Having an implementation of the OptionalAttributes would be very helpful.

So maybe my post gives this issue a little push 🥰

[apparentlymart]

FWIW, I think the main thing for getting this done would be to define some way to represent an optional attribute in the provider protocol and then arrange for Terraform Core to build a function.Parameter whose type constraint is the result of a call to cty.ObjectWithOptionalAttrs.

Once a suitable type constraint is in place, cty itself should take care of automatically inserting the missing attributes with null values before the argument value is passed to the function implementation, and then the provider code could check whether it's null or not.

The wire protocol's version of Parameter.Type is, IIRC, something compatible with what cty.Type.MarshalJSON would produce, and that does have a representation of optional attributes, so I think if you can provide some way to declare them in the framework API and marshal them into that protobuf field then this might "just work" from Terraform Core's perspective, assuming that it's just passing the type buffer to cty.Type.UnmarshalJSON and using the result to construct a function.Parameter. (I'm not sure if that's true, though.)

The JSON representation of an object type with optional attributes looks something like this, IIRC:

[
  "object",
  {
    "name": "string"
  },
  ["name"]
]

...where that final array enumerates all of the attribute names that should be considered as "optional" by cty's type conversion logic. With the above example as the target type, {} would auto-convert to {name = null}.

(If you want to support automatically replacing the nulls with other default values then you could presumably do that on the provider side of the wire protocol once you get the raw value from Terraform Core using null as the placeholder, similar to how default values work for optional arguments on resource types.)