Firewall rule indices: FirewallRuleIndexExisted

[lkubb]

Description I am managing all my firewall rules with this provider. Since I have to give it explicit indices, they are generated naively from a corresponding list index. When I insert a new firewall rule somewhere other than the end, all subsequent indices change as well. This results in a crash of the provider since the update order results in intermittent duplicate indices for possibly many rules, which the controller rejects.

Setup Note that this has existed since I started using the provider (~ 0.34).

Provider version: 0.41 Controller version: 7.3.83 (UDMP)

Logs

Error: api.err.FirewallRuleIndexExisted (400 Bad Request) for PUT https://<host>/proxy/network/api/s/default/rest/firewallrule/<id>

[DEBUG] provider.terraform-provider-unifi_v0.41.0: Received HTTP Response: Set-Cookie="<>; path=/; samesite=none; secure; httponly" tf_resource_type=unifi_firewall_rule Content-Type=application/json;charset=UTF-8 tf_http_res_body={"meta":{"rc":"error","rule_index":2005,"msg":"api.err.FirewallRuleIndexExisted"},"data":[]} [...]

(repeated a lot)

Solutions tried It has been a while since I first tried to solve this, so my memory might be a bit foggy:

• Somehow leaving room in between indices for further updates, but that seemed to be reset by the controller
• parallelism=1
• using terragrunt to reapply the state repeatedly until all rules are at their desired places (this worked somewhat)

Additional context How do you guys manage your rules? I'm considering writing a separate unifi_firewall_ruleset resource for this provider. Not sure if it should just take a list of rule ids and indices to manage or have a top-level view of rules as attribute blocks. Any thoughts?

The UI seems to make use of a reorder command:

# POST to https://<host>/proxy/network/api/s/default/cmd/firewall
{
    "rules":
    [
        {
            "_id": "<id_of_2002>",
            "rule_index": "2001"
        },
        {
            "_id": "<id_of_2001>",
            "rule_index": "2002"
        }
    ],
    "ruleset": "LAN_IN",
    "cmd": "reorder"
}

When moving a rule from the back to the front, it includes each rule that has to be moved with its new index, so it seems it might work as an idempotent command.