Plan output is not displayed or displays null for explicit empty string input

[akinross]

Module version

Terraform v1.6.6
github.com/hashicorp/terraform-plugin-framework v1.4.2

Relevant provider source code

...
"description": schema.StringAttribute{
	Optional: true,
	Computed: true,
	PlanModifiers: []planmodifier.String{
		stringplanmodifier.UseStateForUnknown(),
	},
},
...

Terraform Configuration Files

resource "aci_out_of_band_contract" "example" {
  name = "test_name"
  description = ""
}

Debug Output

Expected Behavior

I expected the plan output to display a "" instead of excluding from plan output or during update changing to null. Is this a limitation or unexpected behaviour?

Actual Behavior

When running a plan on the above configuration snippet the plan output differs from the result I am experiencing in state and on the entity that I am applying the configuration to.

When creating a new resource the description attribute is not displayed in the plan output:

  # aci_out_of_band_contract.example will be created
  + resource "aci_out_of_band_contract" "example" {
      + annotation  = "orchestrator:terraform"
      + annotations = (known after apply)
      + id          = (known after apply)
      + intent      = (known after apply)
      + name        = "test_name"
      + name_alias  = (known after apply)
      + owner_key   = (known after apply)
      + owner_tag   = (known after apply)
      + priority    = (known after apply)
      + scope       = (known after apply)
      + target_dscp = (known after apply)
    }

When I have a resource already configured with a description set to any arbitrary string value I get the following plan output:

  # aci_out_of_band_contract.example will be updated in-place
  ~ resource "aci_out_of_band_contract" "example" {
      + annotations = (known after apply)
      - description = "foobar" -> null
        id          = "uni/tn-mgmt/oobbrc-test_name"
        name        = "test_name"
        # (5 unchanged attributes hidden)
    }

In both scenarios the configuration gets applied correctly to the state file and is correctly configured on the device.

Steps to Reproduce

References

[bflad]

Hi @akinross 👋 Thank you for reporting this and sorry you are running into this confusing behavior.

Real briefly, I believe this may be related to the upstream Terraform issue here: hashicorp/terraform#31887

For various reasons described in that issue, Terraform previously needed to hide these sorts of differences due to the older Terraform Plugin SDK, but the behavior still exists even when using this newer SDK. I am not sure if there is anything we can do within this codebase (or the provider side of the protocol) to help in this situation as we send the correct data over to Terraform, it is just that the plan renderer inside Terraform is hiding these sort of value differences.

[akinross]

HI @bflad, Thank you for the response. It seems to already be 1,5 years old, do you know if the will be introducing a fix for this behaviour?

[bflad]

@akinross I'm reaching out internally to see if that plan renderer fix can be scheduled. 👍

[bflad]

Hi again 👋

After briefly chatting with the upstream Terraform maintainers, the fix here is unfortunately non-trivial since correctly fixing it would involve encoding the prior behavior into saved plans with compatibility promises. The other option would be just changing the planning output to always show these types of differences, causing practitioners stuck using providers built with the older terraform-plugin-sdk to potentially see a lot of relatively-inconsequential value differences that they could not avoid due to how that SDK was written.

Since this issue is unfortunately outside any change we can make in this codebase or terraform-plugin-go (the lower level SDK which this SDK is built), I'm going to close this issue. My best suggestion, if this issue is painful, would be to add a 👍 and potentially a comment in hashicorp/terraform#31887 so those maintainers can weigh the tradeoffs of the situation further. Thanks again for the report though.

[akinross]

Hi @bflad, Thank you for pursuing this upstream. Will try my luck in the upstream thread.

[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.