Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

function.ObjectParameter always requires all arguments #955

Open
jason-johnson opened this issue Mar 15, 2024 · 1 comment
Open

function.ObjectParameter always requires all arguments #955

jason-johnson opened this issue Mar 15, 2024 · 1 comment
Labels
bug Something isn't working enhancement New feature or request

Comments

@jason-johnson
Copy link

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

@jason-johnson jason-johnson added the bug Something isn't working label Mar 15, 2024
@austinvalle
Copy link
Member

austinvalle commented Mar 15, 2024

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 austinvalle added the enhancement New feature or request label Mar 15, 2024
bflad added a commit that referenced this issue Mar 15, 2024
Reference: #955

This attempts to document the existing behavior of Terraform and the framework with relation to object parameters requiring all object attributes to be explicitly configured by adding an early paragraph about the behavior. The other updates on the page are to continue the overall parameter page consistency of configuration examples being used in the implementation examples later in the pages, so here the `attr3` and `null` value handling is shown in all the examples.

In the future, there may be enhancements which could enable "optional" object attributes at which time this new documentation can be updated in relation to that potential new functionality.
bflad added a commit to hashicorp/terraform-provider-corner that referenced this issue Mar 15, 2024
Reference: hashicorp/terraform-plugin-framework#955

This adds acceptance tests that capture the linked issue around object parameter attribute requiredness with the existing behavior of Terraform and available functionality of the framework. These are being added as regression checks should framework functionality ever be introduced that either automatically or enables developers to make object attributes optional. It should be considered a breaking change should the existing function definition begin not causing an error, as provider developers may be reliant and desire this existing behavior for their use cases.

Without `ErrorCheck` (and temporarily `TerraformVersionChecks` to workaround prerelease issues):

```
=== CONT  TestObjectFunction_Known_AttributeRequired_Error
    object_function_test.go:53: Step 1/1 error: Error running pre-apply plan: exit status 1

        Error: Invalid function argument

          on terraform_plugin_test.tf line 13, in output "test":
          13:                                   value = provider::framework::object({
          14:                                           "attr1" = "value1",
          15:                                   })
            ├────────────────
            │ while calling provider::framework::object(param1)

        Invalid value for "param1" parameter: attribute "attr2" is required.
--- FAIL: TestObjectFunction_Known_AttributeRequired_Error (0.30s)
```

With `ErrorCheck`:

```
--- PASS: TestObjectFunction_Known_AttributeRequired_Error (0.48s)
--- PASS: TestObjectFunction_Known_AttributeRequired_Null (0.53s)
```
bflad added a commit to hashicorp/terraform-provider-corner that referenced this issue Mar 15, 2024
…226)

Reference: hashicorp/terraform-plugin-framework#955

This adds acceptance tests that capture the linked issue around object parameter attribute requiredness with the existing behavior of Terraform and available functionality of the framework. These are being added as regression checks should framework functionality ever be introduced that either automatically or enables developers to make object attributes optional. It should be considered a breaking change should the existing function definition begin not causing an error, as provider developers may be reliant and desire this existing behavior for their use cases.

Without `ErrorCheck` (and temporarily `TerraformVersionChecks` to workaround prerelease issues):

```
=== CONT  TestObjectFunction_Known_AttributeRequired_Error
    object_function_test.go:53: Step 1/1 error: Error running pre-apply plan: exit status 1

        Error: Invalid function argument

          on terraform_plugin_test.tf line 13, in output "test":
          13:                                   value = provider::framework::object({
          14:                                           "attr1" = "value1",
          15:                                   })
            ├────────────────
            │ while calling provider::framework::object(param1)

        Invalid value for "param1" parameter: attribute "attr2" is required.
--- FAIL: TestObjectFunction_Known_AttributeRequired_Error (0.30s)
```

With `ErrorCheck`:

```
--- PASS: TestObjectFunction_Known_AttributeRequired_Error (0.48s)
--- PASS: TestObjectFunction_Known_AttributeRequired_Null (0.53s)
```
bflad added a commit that referenced this issue Mar 15, 2024
)

Reference: #955

This attempts to document the existing behavior of Terraform and the framework with relation to object parameters requiring all object attributes to be explicitly configured by adding an early paragraph about the behavior. The other updates on the page are to continue the overall parameter page consistency of configuration examples being used in the implementation examples later in the pages, so here the `attr3` and `null` value handling is shown in all the examples.

In the future, there may be enhancements which could enable "optional" object attributes at which time this new documentation can be updated in relation to that potential new functionality.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants