bug: time_rotationg with timecmp

[tsanton]

Terraform CLI and Provider Versions

Terraform v1.5.3 on linux_amd64

• provider registry.terraform.io/hashicorp/time v0.9.1

Terraform Configuration

terraform {
  required_providers {
    time = {
      source  = "hashicorp/time"
      version = "0.9.1"
    }
  }
}
provider "time" {}

resource "time_static" "init_apply" {}

locals {
  change_timestamp = timeadd(time_static.init_apply.rfc3339, "30s")
}

resource "time_rotating" "this" {
  rotation_minutes = timecmp(timestamp(), local.change_timestamp) == 1 ? 1 : 2
}

output "test" {
  value = {
    timecmp          = timecmp(timestamp(), local.change_timestamp)
    now              = timestamp()
    rfc3339          = time_rotating.this.rfc3339
    rotation_rfc3339 = time_rotating.this.rotation_rfc3339
  }
}

Expected Behavior

Subsequent plan & apply actions to work, not reverting the time_rotation resource to "0001-01-01T00:00:00Z" & breaking due to provider bugs.

Actual Behavior

The first apply goes through and all is well. On subsequent plans and applies prior when timestamp() > time_rotating.this.rotation_rfc3339 all is good. On subsequent plans and applies prior when timestamp() < time_rotating.this.rotation_rfc3339 the time_rotating.this resource reports an update

# time_rotating.this will be updated in-place
  ~ resource "time_rotating" "this" {
      ~ day              = 21 -> 1
      ~ hour             = 10 -> 0
        id               = "2023-07-21T10:53:44Z"
      ~ minute           = 54 -> 0
      ~ month            = 7 -> 1
      ~ rotation_minutes = 1 -> (known after apply)
      ~ rotation_rfc3339 = "2023-07-21T10:54:44Z" -> "0001-01-01T00:00:00Z"
      ~ second           = 44 -> 0
      ~ unix             = 1689936884 -> -62135596800
      ~ year             = 2023 -> 1
        # (1 unchanged attribute hidden)
    }

Applying this breaks with the following error message:

Error: Provider produced inconsistent final plan
│ 
│ When expanding the plan for time_rotating.this to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/time" produced an invalid
│ new value for .hour: was cty.NumberIntVal(0), but now cty.NumberIntVal(10).
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent final plan
│ 
│ When expanding the plan for time_rotating.this to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/time" produced an invalid
│ new value for .month: was cty.NumberIntVal(1), but now cty.NumberIntVal(7).
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent final plan
│ 
│ When expanding the plan for time_rotating.this to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/time" produced an invalid
│ new value for .day: was cty.NumberIntVal(1), but now cty.NumberIntVal(21).
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent final plan
│ 
│ When expanding the plan for time_rotating.this to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/time" produced an invalid
│ new value for .rotation_rfc3339: was cty.StringVal("0001-01-01T00:00:00Z"), but now cty.StringVal("2023-07-21T10:54:44Z").
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent final plan
│ 
│ When expanding the plan for time_rotating.this to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/time" produced an invalid
│ new value for .second: was cty.NumberIntVal(0), but now cty.NumberIntVal(44).
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent final plan
│ 
│ When expanding the plan for time_rotating.this to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/time" produced an invalid
│ new value for .unix: was cty.NumberIntVal(-6.21355968e+10), but now cty.NumberIntVal(1.689936884e+09).
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent final plan
│ 
│ When expanding the plan for time_rotating.this to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/time" produced an invalid
│ new value for .minute: was cty.NumberIntVal(0), but now cty.NumberIntVal(54).
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent final plan
│ 
│ When expanding the plan for time_rotating.this to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/time" produced an invalid
│ new value for .year: was cty.NumberIntVal(1), but now cty.NumberIntVal(2023).
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Steps to Reproduce

1. terraform apply 2.terraform apply (when timestamp() < time_rotating.this.rotation_rfc3339)

How much impact is this issue causing?

Low

Logs

No response

Additional Information

It's a horrible implementation meant to POC a rotation strategy of client credentials. It will never actually be implemented as such, but for a quick and dirty demonstration of a rotation strategy with an initial offset of rotation time fixing this would be practical.

Code of Conduct

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

[tsanton]

And here is the TF_LOG=debug: tf_log.txt

[SBGoods]

Hi @Tsanton, Sorry that you are running into trouble here. This issue likely stems from the rotation_minutes attribute being updated with an Unknown value during planning as the timestamp() function is not evaluated til the apply step. Unfortunately, due to the nature of this resource, we cannot fix this issue as it would cause preemptive rotations to occur. If you are using Terraform v1.5.0 and above you can use plantimestamp(), which evaluates a timestamp during planning, instead to circumvent this error.