In Cloudflare v4.41, using an expression with "in {item1 item2}" in cloudflare_rule causes terraform to fail on an Terraform Apply. Issue does not exist in v4.18

[virtualjack]

Confirmation

• 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.
• I have searched the issue tracker and my issue isn't already found.
• I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version

Terraform v1.7.5 on linux_amd6
cloudflare/cloudflare v4.41.0 (self-signed, key ID C76001609EE3B136)

Affected resource(s)

cloudflare_ruleset

This error impacts v4.41 of the Cloudflare Terraform provider but not v4.18

Terraform configuration files

resource "cloudflare_ruleset" "dynamic_restrictions" {
  account_id  = var.cloudflare_account_id
  name        = "Rules for development environment"
  description = "Restrict traffic to dev environment"
  kind        = "custom"
  phase       = "http_request_firewall_custom"

 rules {
    action      = "block"
    expression  = "(not ip.geoip.asnum in {XXX YYY} )"
    description = "Block all traffic not originating from SEI ASN"
    enabled     = true
  }
}

Link to debug output

NA

Panic output

Error: error updating ruleset with ID "8f9137da29324de2812f46fc0db33e16"

with module.acct_firewall.cloudflare_ruleset.dynamic_restrictions,
on modules/acct_firewall/dev_environment_ruleset.tf line 2, in resource "cloudflare_ruleset" "dynamic_restrictions":
2: resource "cloudflare_ruleset" "dynamic_restrictions" {

'not ip.geoip.asnum in {17276 14056})' is not a valid value for expression
because the expression is invalid: Filter parsing error (1:36):
not ip.geoip.asnum in {17276 14056})
^ unrecognised input
(20127)

Expected output

module.acct_firewall.cloudflare_ruleset.dynamic_restrictions: Modifying... [id=6ec095c441e14043bb26b9505f5cf2d5]

Actual output

Error: error updating ruleset with ID "8f9137da29324de2812f46fc0db33e16"

with module.acct_firewall.cloudflare_ruleset.dynamic_restrictions,
on modules/acct_firewall/dev_environment_ruleset.tf line 2, in resource "cloudflare_ruleset" "dynamic_restrictions":
2: resource "cloudflare_ruleset" "dynamic_restrictions" {

'not ip.geoip.asnum in {17276 14056})' is not a valid value for expression
because the expression is invalid: Filter parsing error (1:36):
not ip.geoip.asnum in {17276 14056})
^ unrecognised input
(20127)

Steps to reproduce

create a rule with expression that contains "in {item1 item2}" and run it with v4.41 of the Cloudflare provider and you will get an error. Run it with v4.18 of the Cloudflare provider and the rule will deploy successfully.

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]

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.

This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.