Managing Cloudflare Ruleset Order via Terraform

[maheedharTumpudi]

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 version : 1.3.9
cloudflare provider version : 4.46.0

Affected resource(s)

cloudflare_ruleset

Terraform configuration files

This is my input
zone_name: wildcardtest2.factset.com
name: wildcardtest2-redirect
description: redirect rules for wildcardtest2.factset.com zone
phase: http_request_dynamic_redirect
kind: zone
redirect_rules:
  - name: test-redirect3
    description: Redirect for test-redirect3
    target_url: https://go.test.com/test3
    preserve_query_string: true
    expression: (http.host eq \"test3.com\") or (http.host eq \"go.test3.com\") or (http.host eq \"www.test3.com\")
    rule_type: static
  - name: test-dynamic-redirect1
    description: Redirect for test-dynamic-redirect1
    target_expression: lower(concat(\"https://\", ip.geoip.country, \".example.com\"))
    preserve_query_string: true
    expression: (http.host eq \"testdynamic.com\") or (http.host eq \"go.testdynamic.com\") or (http.host eq \"www.testdynamic.com\")
    rule_type: dynamic
  - name: test-dynamic-redirect2
    description: Redirect for test-dynamic-redirect2
    target_expression: lower(concat(\"https://\", ip.geoip.country, \".example2.com\"))
    preserve_query_string: true
    expression: (http.host eq \"testdynamic2.com\") or (http.host eq \"go.testdynamic2.com\") or (http.host eq \"www.testdynamic2.com\")
    rule_type: dynamic

This is my module
resource "cloudflare_ruleset" "static-redirect-rule" {
  zone_id     = var.zone_id
  name        = var.name
  description = var.description
  kind        = var.kind
  phase       = var.phase

  dynamic "rules" {
    for_each = var.redirect-rules
    content {
      action = "redirect"
      action_parameters {
        from_value {
          status_code = 301
          target_url {
            value      = rules.value.target-url != "" ? rules.value.target-url : null
            expression = rules.value.target-expression != "" ? rules.value.target-expression : null
          }
          preserve_query_string = rules.value.preserve-query-string
        }
      }
      expression  = rules.value.expression
      description = rules.value.name
      enabled     = true
    }
  }
}

Link to debug output

NA

Panic output

No response

Expected output

When i try to delete 2nd rule from the input file i expect the plan generated to just remove that rule and doensot impact rest of the rules.

Actual output

But the plan generated is modifying all the rules after second rule and then deleting the second rule as these rules are order oriented.

Steps to reproduce

1. Try to remove any rule from middle of the input file.
2. Generate terraform plan with modified input file.

Additional factoids

We are currently managing and creating Cloudflare rulesets and rules across multiple zones using Terraform. As you know, the rules in Cloudflare are order-sensitive. Whenever we generate a Terraform plan that includes changes—such as the deletion or addition of a new rule—it results in changes to the order of all existing rules. This is reflected in the Terraform plan, causing updates to all the rules, even when their actual content remains unchanged. We would like to inquire if there is a way to manage or specify the order of rules directly within the Terraform configuration. Specifically:

Is there an attribute or approach in Terraform that allows us to define a rule's order explicitly, ensuring only the intended changes are applied without affecting unrelated rules?
If no such feature currently exists, is there a recommended best practice for managing ordered rulesets in Terraform while minimizing the impact on existing rules?
Are there alternative solutions or APIs that can help us achieve this level of control?
We are seeking a method to avoid unnecessary modifications to unrelated rules when making changes, as this can have implications for both deployment workflows and rule stability.

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.

[jacobbednarz]

i can't speak to your example here (i don't quite understand how/why you're doing what you're doing) however, inserting or removing one of the rules is expected to show a diff of replacing all the remaining rules as they are explicitly ordered. so while you may have rule 1, 2, and 3, if you remove rule 1, you are actually moving rule 2 -> 1 and rule 3 -> 2 which terraform needs to reflect in the state and API calls.