cloudflare_list does not handle IPv6 octets with a leading zero correctly

[kenske]

Confirmation

• [x] This is a bug with an existing resource and is not a feature request or enhancement. Feature requests should be submitted with Cloudflare Support or your account team.
• [x] I have searched the issue tracker and my issue isn't already found.
• [x] I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version

OpenTofu v1.10.2 on linux_amd64

• provider registry.opentofu.org/cloudflare/cloudflare v5.10.1

Affected resource(s)

cloudflare_list

Terraform configuration files

resource "cloudflare_list" "test_list" {
  name       = "test_list"
  kind       = "ip"
  account_id = "my-id"
  items = [
    {
      ip      = "2803:9810:4831:6d10:cda2:5eab:0b9a:8fd2"
      comment = "spammer"
    }
  ]
}

Link to debug output

N/A

Panic output

No response

Expected output

Resource applied successfully

Actual output

│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to cloudflare_list.test_list, provider "provider[\"registry.opentofu.org/cloudflare/cloudflare\"]" produced an unexpected new value: .items: planned set element
│ cty.ObjectVal(map[string]cty.Value{"asn":cty.NullVal(cty.Number), "comment":cty.StringVal("spammer"), "hostname":cty.NullVal(cty.Object(map[string]cty.Type{"exclude_exact_hostname":cty.Bool,
│ "url_hostname":cty.String})), "ip":cty.StringVal("2803:9810:4831:6d10:cda2:5eab:0b9a:8fd2"), "redirect":cty.NullVal(cty.Object(map[string]cty.Type{"include_subdomains":cty.Bool,
│ "preserve_path_suffix":cty.Bool, "preserve_query_string":cty.Bool, "source_url":cty.String, "status_code":cty.Number, "subpath_matching":cty.Bool, "target_url":cty.String}))}) does not
│ correlate with any element in actual.
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Steps to reproduce

1. Create a cloudflare_list resource of type "ip"
2. Add IPv6 addresses, with one of the octets having a leading zero
3. Apply

Additional factoids

No response

References

No response

[KaydeeDee]

Thank you for submitting an issue! I've created a ticket for the team to investigate.

[broswen]

The API normalizes IPv6 by removing leading 0s. It looks like the Provider will have to be updated to consider those changes semantically equivalent.

@kenske , I'm curious if it is possible to normalize them before you use them with Terraform as a workaround? How are you generating this list of IPs?

[kenske]

@broswen Yes, I normalized them manually as a workaround. I'm getting this list by parsing an external CSV.

[KaydeeDee]

Hi there - For a work around for now, you can normalize your IPs via https://developer.hashicorp.com/terraform/language/functions/trimsuffix

trimsuffix(trimsuffix(ip, "/32"), "/128")

[kenske]

@KaydeeDee Did you mean to comment this on a different issue? Suffixes are not related to this issue.

[fholzer]

I am not sure this is specific to IPv6 IP addresses. I am getting this error for both IPv4 and IPv6 addresses. The interesting thing is that Terraform says that the "new unexpected" items it prints as part of the error message are exactly as specified in my resource. So no optional leading zero that could confuse TF.