terraform plan hides unchanged attributes even if they forces replacement

[ndrpnt]

Terraform CLI and Provider Versions

Terraform v1.5.7
on darwin_amd64
+ provider registry.terraform.io/hashicorp/tls v4.0.6

Terraform Configuration

resource "tls_private_key" "key" {
  algorithm = "ED25519"
}

resource "tls_self_signed_cert" "cert" {
  private_key_pem       = tls_private_key.key.private_key_pem
  validity_period_hours = 0
  allowed_uses          = []
}

Expected Behavior

The ready_for_renewal attribute should be shown with a forces replacement comment. Even though its value does not change, it forces the resource to be replaced due to this line in the provider.

Actual Behavior

When running terraform plan, it is unclear why the certificate is being replaced because the attribute forcing the replacement is hidden:

tls_private_key.key: Refreshing state... [id=645bcc302e999c30e780c2c673a8b38803a5c161]
tls_self_signed_cert.cert: Refreshing state... [id=95418850290231087350800214566494560444]

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

Terraform will perform the following actions:

  # tls_self_signed_cert.cert must be replaced
-/+ resource "tls_self_signed_cert" "cert" {
      ~ cert_pem              = <<-EOT
            -----BEGIN CERTIFICATE-----
            MIHNMIGAoAMCAQICEEfJAInXcv5Nkq+XPa4YYLwwBQYDK2VwMAAwHhcNMjQxMTI1
            MjAxMTUzWhcNMjQxMTI1MjAxMTUzWjAAMCowBQYDK2VwAyEAVk4SSSMuXfcd0ZXE
            sa2XXFZMXjJNfAJEeHAVrYQdTkyjEDAOMAwGA1UdEwEB/wQCMAAwBQYDK2VwA0EA
            Evd8VovJCZyA8SHtBYU+cJvMWJ+7lhfDkDTfK2tGuq6cDeBxsCbv2m7oRepYS48k
            0zV20I3X9ymaKnul/8UkDA==
            -----END CERTIFICATE-----
        EOT -> (known after apply)
      ~ id                    = "95418850290231087350800214566494560444" -> (known after apply)
      ~ key_algorithm         = "ED25519" -> (known after apply)
      ~ validity_end_time     = "2024-11-25T21:11:53.935539+01:00" -> (known after apply)
      ~ validity_start_time   = "2024-11-25T21:11:53.935539+01:00" -> (known after apply)
        # (8 unchanged attributes hidden)
    }

Plan: 1 to add, 0 to change, 1 to destroy.

Steps to Reproduce

1. terraform init
2. terraform apply
3. terraform plan

How much impact is this issue causing?

Low

Logs

No response

Additional Information

This can happen in a least two (edge) cases:

• validity_period_hours = 0 which implies that ready_for_renewal is always true
• terraform plan -refresh=false with a non-zero validity_period_hours, which implies that ready_for_renewal is always false

In both cases ready_for_renewal does not change, hence it is hidden during plan, even though it forces a replacement.

I opened hashicorp/terraform#36097, because I think that Terraform core should show attributes that force a replacement even if they are unchanged. However it is considered working as expected. It is the responsibility of the provider to never require a replacement on an unchanged attribute.

Maybe associating the requireReplace to the validity_{start, end}_time as well would make sense.

Code of Conduct

• I agree to follow this project's Code of Conduct

[austinvalle]

Hey there @ndrpnt 👋🏻 , thanks for reporting the issue! This is definitely an awkward bug and I can confirm what the core team mentioned that it is being caused by the TLS provider, likely introduced in #268.

I'm not really sure if there is an alternative that we would prefer here, since the reason the diff isn't showing is because it's doing a fresh "create" plan on tls_self_signed_cert once Terraform is informed it needs to be replaced. That "create" plan will always end up with ready_for_renewal as true with that config, as you mentioned, regardless of the "replacement plan" returning unknown for tls_self_signed_cert, which then manifests in the lack of a diff you're seeing.

I think the only real solution we could do here is always mark ready_for_renewal as unknown when the plan is creating, although I haven't thought through what the impact of that would be on existing configurations.

[ndrpnt]

Agree, marking ready_for_renewal as unknown seems to be an elegant solution. I can't think of a negative impact: the plan will indicate ready_for_renewal = true -> (known after apply) instead of ready_for_renewal = true -> false, but I'm no expert.