SingleNestedAttribute - Plan detects unexisting changes

[adamkrim]

Hello,

In a SingleNestedAttribute, I think that computed attributes do not coexist well with optional-computed.

Here is my code, I have a SingleNestedAttribute that contains a configurable boolean and a read-only info.

{
 ...
 "firewall": schema.SingleNestedAttribute{
	Optional:            true,
	Computed:            true,
	Attributes: map[string]schema.Attribute{
		"enabled": schema.BoolAttribute{
			Optional:            true,
			Computed:            true,
			PlanModifiers: []planmodifier.Bool{
				modifiers.BoolDefault(true), // true if not specified
			},
		},
		"ports": schema.StringAttribute{
			Computed:            true,
		},
	},
 ...
}

Here is my main.tf (in both examples, firewall.enabled = true)

resource "elestio_postgres" "mypostgres1" {
  name
}

resource "elestio_postgres" "mypostgres2" {
  name
  firewall = {
    enabled = true
  }
}

If I execute terraform apply or terraform plan, mypostgres2 will always detect a change, event if the firewall is already enabled.

I know that it comes from these attributes because postgres1 does not have the problem.
If I remove the ports attribute, the problem disappears.

Do you know a solution?
I don’t really want to create two singleNestedAttributes with configurable ones on one side, and read-only ones on the other.

Thanks for your time

[iwarapter]

Hey I think we have the same problem:

Adding a computed SingleNestedAttribute to a resource causes other fields show (known after apply)

[bflad]

Hi @adamkrim Thank you for raising this topic.

Terraform requires knowing upfront during planning when an attribute value may change, otherwise it can cause a practitioner-facing error or, in the case of a Computed only attribute, may require two applies to successfully update downstream value references. The framework opts to this unknown value behavior by default, rather than potentially letting provider developers unexpectedly cause practitioner-facing errors by default.

Is the ports values expected to change ever? If not, adding the UseStateForUnknown() plan modifier will prevent the framework from showing the known to unknown value plan difference by copying the existing prior state value into the planned value. If the value can change, then you will likely need to implement plan modification logic to match the API’s behavior (and Consider UnknownIf Attribute Plan Modifiers · Issue #605 · hashicorp/terraform-plugin-framework · GitHub might be of interest for something more baked into the framework).