Ignore rule expiration date doesn't work

[luis-garza]

Describe the bug

The Ignore rule expiration date field doesn't work as expected. The ignore rule is created but with one day less in the expiration date from the date defined. So, any further plan or apply will end up with an inconsistency error:

Below is the snippet:

resource "xray_ignore_rule" "vulnerabilities" {
    cves            = [
        "CVE-2024-47554",
        "CVE-2024-7254",
    ]
    expiration_date = "2024-10-25"
    notes           = "CVE-7254-47554"
    project_key     = "foo"
    watches         = [
        "bar"
    ]
    component {
        name = "gav://com.google.protobuf:protobuf-java"
    }
    component {
        name = "gav://commons-io:commons-io"
    }
}

Below is the behavior:

xray_ignore_rule.vulnerabilities[CVE-7254-47554"]: Refreshing state... [id=d06ddbd2-fb64-4af7-4389-93ed974e39b5]

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:

  # xray_ignore_rule.vulnerabilities["CVE-7254-47554"] is tainted, so must be replaced
-/+ resource "xray_ignore_rule" "vulnerabilities" {
      ~ author          = "rxpinte0" -> (known after apply)
      ~ created         = "2024-10-18T08:47:52Z" -> (known after apply)
      ~ expiration_date = "2024-10-24" -> "2024-10-25"
      ~ id              = "d06ddbd2-fb64-4af7-4389-93ed974e39b5" -> (known after apply)
      ~ is_expired      = false -> (known after apply)
        # (4 unchanged attributes hidden)

        # (3 unchanged blocks hidden)
    }

Plan: 1 to add, 0 to change, 1 to destroy.
xray_ignore_rule.vulnerabilities["CVE-7254-47554"]: Destroying... [id=d06ddbd2-fb64-4af7-4389-93ed974e39b5]
xray_ignore_rule.vulnerabilities["CVE-7254-47554"]: Destruction complete after 0s
xray_ignore_rule.vulnerabilities["CVE-7254-47554"]: Creating...
╷
│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to
│ xray_ignore_rule.vulnerabilities["CVE-7254-47554"],
│ provider "provider[\"registry.terraform.io/jfrog/xray\"]" produced an
│ unexpected new value: .expiration_date: was cty.StringVal("2024-10-25"),
│ but now cty.StringVal("2024-10-24").
│ 
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.
╵

[alexhung]

@luis-garza Thanks for the report. I'll add this to our plan to investigate.

At first glance, this may be timezones related. Are you (where you apply TF configuration) in the same timezone as your Artifactory instance?

[luis-garza]

At first glance, this may be timezones related. Are you (where you apply TF configuration) in the same timezone as your Artifactory instance?

Yes, both are in the same TZ.
TF module is executed in UTC+1, and we're using EU SaaS artifactory instance.

[luis-garza]

Hi, here's an update.
The issue I've faced was with the provider v2.12.0, but it looks like the issue disappeared upgrading to the latest one, v2.13.0.
It's weird as the changelog doesn't mention anything related to the expiration date:

• Add multiple tfc workload identity tokens support by @alexhung in Add multiple tfc workload identity tokens support #257
• Bump golang.org/x/text from 0.18.0 to 0.19.0 by https://github.com/dependabot in Bump golang.org/x/text from 0.18.0 to 0.19.0 #255

Not sure if the issue was fixed by the lib upgrade, or by some external change at server side... 🤔
Please confirm the issue is solved by the lib upgrade an it won't be reproduced again.

[alexhung]

@alexhung If the issue is resolved in v2.13.0, it was not intentional or planned.

[luis-garza]

So, here's again the issue... 😢
As expected, if it goes out magically, it will come again magically! 😅

This random failures smells that it could be related to the time when it's executed.

This one was executed on Oct 29th at 11:40 from Spain (GMT+1) and was performed against European Artifactory SaaS instance.

Terraform will perform the following actions:
  # xray_ignore_rule.vulnerabilities["my-rule"] will be created
  + resource "xray_ignore_rule" "vulnerabilities" {
      + author          = (known after apply)
      + created         = (known after apply)
      + cves            = [
          + "CVE-2018-20225",
        ]
      + expiration_date = "2024-11-25"
      + id              = (known after apply)
      + is_expired      = (known after apply)
      + notes           = "my-rule"
      + project_key     = "ni"
      + watches         = [
          + "ni-vulnerabilities",
        ]
      + artifact {
          + name = "docker://python"
        }
      + component {
          + name = "pypi://pip"
        }
    }
Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.
  Enter a value: 
xray_ignore_rule.vulnerabilities["my-rule"]: Creating...
╷
│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to xray_ignore_rule.vulnerabilities["my-rule"],
│ provider "provider[\"registry.terraform.io/jfrog/xray\"]" produced an
│ unexpected new value: .expiration_date: was cty.StringVal("2024-11-25"),
│ but now cty.StringVal("2024-11-24").
│ 
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.
╵```

If I find another executions where it works, I'll post here all info...

[alexhung]

This random failures smells that it could be related to the time when it's executed.

@luis-garza That was my initial guess as well (TZ related). I'll take a look at the code in the next few days.

[luis-garza]

PR is open, nice!

If you let us know how we can grab the artifact from the CI we can check it.

[alexhung]

@luis-garza We don't save the binary from our CI acceptance tests. You can pull the branch and build the binary yourself but that's probably too much setup?

[luis-garza]

@alexhung hey, I've just tested the fix published.
It works like a charm! 😉