Changing a single IP in a cloudflare_list causes subsequent IPs to change

[rickardp]

Confirmation

• My issue isn't already found on the issue tracker.
• I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version

(Possibly related to #2538)

Affected resource(s)

• cloudflare_list

Terraform configuration files

resource "cloudflare_list" "whitelisted_ips" {
  account_id  = var.account_id
  name        = var.ip_whitelist_name
  kind        = "ip"
  description = var.ip_whitelist_description

  dynamic "item" {
    for_each = toset(local.whitelisted_ranges)
    content {
      value {
        ip = item.value
      }
    }
  }
}

Link to debug output

https://gist.github.com/rickardp/715aaca98bada8f75334dd1ad77f92bc

Panic output

No response

Expected output

No diff

Actual output

    # cloudflare_list.whitelisted_ips will be updated in-place
      ~ resource "cloudflare_list" "whitelisted_ips" {
            id          = "(redacted)"
            name        = "(redacted)"
            # (3 unchanged attributes hidden)
...
 - item {
              - value {
                  - asn = 0 -> null
                  - ip  = "1.2.3.4" -> null
                }
            }
....
 + item {
              + value {
                  + ip = "1.2.3.4"
                }
            }

Steps to reproduce

1. Modify an IP in the set of IP ranges
2. Run terraform plan
3. Observe that it wants to both delete and insert the same items, items unrelated to the actual added and/or removed items

Additional factoids

No response

References

No response

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[github-actions]

Terraform debug log detected ✅

[github-actions]

Thank you for opening this issue and sorry to hear you're hitting issues. Unfortunately, the reproduction case provided contains HCL dynamic expressions. Examples of these are:

• Conditionals
• For loops
• Dynamic blocks
• Modules and module references

Maintainers don't accept these as reproduction cases since using these constructs and expressions can hold their own logic bugs which are outside of the provider and not able to be diagnosed.

For maintainers to triage this issue, we recommend providing a minimal reproduction test case that is only contains the impacted resources and can be easily reproduced in an isolated environment. Without providing this, maintainers are limited in what support they can provide.

[bhartm3]

We have the same issue on v4.18 and now v4.20 and subsequent apply commands always reset the list even though we dont change anything, seemingly caused by wanting to set the asn = 0 -> null for an IP.

[rickardp]

Unfortunately, the reproduction case provided contains HCL dynamic expressions

Can we get a maintainer to look at this please? The bot comment above is invalid, as this issue might be caused by the dynamic expressions and this must work. The repro case above is self contained and is expected to work.

[niklasweimann]

We are experiencing the same issue. It seems that it is related to kind="ip" as the API returns ASN as 0 on subsequent runs, but ASN is null in the Terraform state which results in a change required by Terraform. Setting ASN to 0 does not mitigate the issue as 0 is not allowed as an ASN.

[jacobbednarz]

@rickardp the bot comment is not invalid. you have not provided the full debug log output which is used for diagnosis and you're using dynamics which we don't accept for reproduction cases for the reasons mentioned. if you provide the requested details, this can be triaged.

@niklasweimann if you have the debug logs and reproduction case available, we can also use that instead for investigation.

[rickardp]

@rickardp the bot comment is not invalid. you have not provided the full debug log output which is used for diagnosis and you're using dynamics which we don't accept for reproduction cases for the reasons mentioned. if you provide the requested details, this can be triaged.

@niklasweimann if you have the debug logs and reproduction case available, we can also use that instead for investigation.

The IP list is from a dynamic source. I don't see why my use case would not be valid. Are you saying that this resource does not work with dynamic blocks and this is by design?

Naturally I am not going to provide a full debug log of my IaC output on the public internet. I kept the part where the versions were printed in the hope that this sufficed. I am happy to provide more details privately if you prefer.

[niklasweimann]

Hey @rickardp 👋
Here the debug log of an RUN which results in the described change. I have removed all ips, Entries not Related to the cloudflare_list and sensitive data:
log.txt

[rickardp]

Hey @rickardp 👋 Here the debug log of an RUN which results in the described change. I have removed all ips, Entries not Related to the cloudflare_list and sensitive data: log.txt

Thank you, @niklasweimann I can confirm this shows the same behaviour as I had.

@jacobbednarz Is anyone looking into this issue?

[NumOneFan]

This seems to be a bug in the update logic for cloudflare list items, resulting in erroneous reordering of entries when there are in fact no changes. This is not reproducible without the for_each statement, because a list with only one item is always in the same order.

[wjdavis5]

Curious when we can expect this to be resolved. It is generating alot noise in plans that make it easy to overlook other undesirable outcomes. I think we're just going to open a support case on this to hopefully get some eyes on it.

[7jPUn4w8caDX]

First you create a IP list using cloudflare_list resource

resource "cloudflare_list" "example" {
  account_id  = var.cloudflare_account_id
  name        = "list_test_delete"
  description = "example IPs for a list"
  kind        = "ip"

  item {
    value {
      ip = "192.0.2.0"
    }
    comment = "one"
  }

}

Then, you add a new item inside the same resource

resource "cloudflare_list" "example" {
  account_id  = var.cloudflare_account_id
  name        = "list_test_delete"
  description = "example IPs for a list"
  kind        = "ip"

  item {
    value {
      ip = "192.0.2.0"
    }
    comment = "one"
  }

  item {
    value {
      ip = "192.0.2.1"
    }
    comment = "two"
  }
  
}

Terraform will plan to delete the first one and add all back.

  # cloudflare_list.example will be updated in-place
  ~ resource "cloudflare_list" "example" {
        id          = "<redacted-account-id>"
        name        = "list_test_delete"
        # (3 unchanged attributes hidden)

      - item {
          - comment = "one" -> null

          - value {
              - asn = 0 -> null
              - ip  = "192.0.2.0" -> null
            }
        }
      + item {
          + comment = "one"

          + value {
              + ip = "192.0.2.0"
            }
        }
      + item {
          + comment = "two"

          + value {
              + ip = "192.0.2.1"
            }
        }
    }

Here is the associated gist: https://gist.github.com/7jPUn4w8caDX/241ad64c031a386fe8bfc1ab8e4e6ca8

[wjdavis5]

CF support came back to us stating that the issue was that we were explicitly specifying a /32 in our addresses. We confirmed that removing the /32 from our input resolved the issue with the plan tearing the list down and rebuilding it. Looking at the OG post here it appears you're manually specifying an ASN=0, perhaps try removing any ASN=0 from your input.

Here is our current terraform block

resource "cloudflare_list" "ip_whitelist" {
  account_id  = var.cloudflare_account_id
  name        = "ip_whitelist"
  description = "ip_whitelist"
  kind        = "ip"

  dynamic "item" {
    for_each = local.whitelist_data
    content {
      value {
        ip = replace(item.value.Address, "/32", "") 
      }
      comment = item.value.Source
    }
  }
}