Metadata flattener refactor breaks data resource null checks

[dghubble]

Terraform Version, Provider Version and Kubernetes Version

Terraform version: v1.6.4
Kubernetes provider version: v2.26.0
Kubernetes version: v1.29.2

Affected Resource(s)

• data.kubernetes_secret (likely others)

Terraform Configuration Files

Before terraform-provider-kubernetes v2.25.0, it was possible to use a data reference for a Kubernetes Secret that doesn't exist yet, and then check whether the value was null in expressions.

data "kubernetes_secret" "tls" {
  metadata {
    name = "example"
  }
}

...

locals {
   foo = data.kubernetes_secret.tls.data != null ? "foo" : "bar"
}

Debug Output

Panic Output

Steps to Reproduce

Expected Behavior

What should have happened?

The prior behavior was useful since you could act on a missing secret in advanced ways. And now that's no longer possible :(

You should be allowed to data reference a non-existent secret and check whether it's value is null. This should not hard error out the workspace.

Actual Behavior

What actually happened?

Starting with v2.25.0 in this refactor, the behavior broke. You just get a hard error and the Terraform workspace is unusable unless you remove the data reference.

Error: secrets "example" not found
│ 
│   with module.secrets-sync,
│   on tls-secret/tls.tf line 3, in data "kubernetes_secret" "tls":
│    3: data "kubernetes_secret" "tls" {

The prior behavior was useful since you could act on a missing secret in advanced ways. And now that's no longer possible :(

Important Factoids

Rolling back to provider v2.24.0 fixes this again.

References

• https://github.com/hashicorp/terraform-provider-kubernetes/pull/2345

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[dghubble]

cc @arybolovlev

[alexsomesan]

Hi Dalton, Thanks for the report and catching this. Indeed, you are right. This does look like a regression, especially as a minor version release. We'll address it shortly.

[alexsomesan]

Release 2.29.0 contains the fix.