Change not triggered for optional / computed string field when set to empty string

[timofurrer]

In one of my resources I have the following schema:

"some_attr": {
   Type: schema.TypeStr,
   Optional: true,
   Computed: true,
}

When changing from this config:

resource "some_res" "this" {
   some_attr = "foo"
}

to this:

resource "some_res" "this" {
  some_attr = ""
}

it won't trigger a change, because of this:

terraform-plugin-sdk/helper/schema/schema.go

Line 565 in ac0b965

log.Println("[DEBUG] A computed value with the empty string as the new value and a non-empty old value was found. Interpreting the empty string as \"unset\" to align with legacy behavior.")

What's the proper way to solve this situation?

In this case some_attr is optional and the "infrastructure" may set it to something (hence the computed) or the terraform user can chose to do so.

[bflad]

Hi @timofurrer 👋 Thank you for raising this and sorry you ran into this frustrating behavior.

This SDK unfortunately implements some automatic behaviors which are difficult to workaround in provider implementations. Schema attributes that are set as Optional + Computed will preserve their known prior state value if a configuration value changes to null or a zero-value of the type (e.g. "" for strings). Changing this behavior would require a major version release since many providers are reliant on the existing behavior.

I do not believe there is a workaround for this except to potentially introduce a separate attribute that gets filled in with the infrastructure value so Computed can be removed from the configurable attribute and disable the automatic behavior. It may also be possible to use a Default value if there is an appropriate default infrastructure value to trigger the SDK to treat an empty string as different.

The team that maintains this SDK has been working on a reimagined development experience that does not have this automatic behavior over in the Terraform Plugin Framework. The Which SDK? page can provide some guidance on whether to adopt that SDK is appropriate and the framework documentation is now includes a Migrating from SDK section. It is targeted for a version 1.0.0 release next month.

[timofurrer]

@bflad 👋 Thanks for the answer!

It is targeted for a version 1.0.0 release next month.

What's the best way to follow that release (schedule) ?

[bflad]

To be notified when the release happens, you can watch the terraform-plugin-framework GitHub repository's releases, watch the Plugin Development section in HashiCorp Discuss, or subscribe to the HashiCorp blog.

As for the scheduling, you can see the remaining items drop out of the v1.0.0 milestone as they move into other milestones.