Local rule deletion doesnt commit to the cloudngfw firewall

[shankar-bala]

Is there an existing issue for this?

• I have searched the existing issues

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment and review the contribution guide to help.

Terraform Version

v1.3.7

AzureRM Provider Version

3.75.0

Affected Resource(s)/Data Source(s)

azurerm_palo_alto_local_rulestack_rule

Terraform Configuration Files

terraform {
    required_providers {
        azurerm = {
            source = "hashicorp/azurerm"
            version = "=3.75.0"
        }
    }
}

provider "azurerm" {
    features {}
}

Debug Output/Panic Output

log files are available here - https://gist.github.com/shankar-bala/be2c7ef8849ac8463179475ea348628c

tfdebug-log-createrule.txt - logfile for rule1 create
tfdebug-log-deleterule.txt - logfile for rule1 delete
tfdebug-log-createrule2.txt - logfile for rule2 create

Expected Behaviour

Cloudngfw firewall should not have the rule that got deleted.

Actual Behaviour

local rule deletion not triggering a commit and the firewall still see the old rule. To perform deletion., new rule must be added.

Steps to Reproduce

1. Create firewall resource with empty rulestack.
2. Attach a rule1 to the rulestack and perform terraform apply.
3. Verify the rule1 presence from the firewall console.
4. Delete the rule1 and perform terraform apply.
5. Rule1 must be deleted from the firewall -> this is missing...we still see the rule1 present in the firewall and dont see any commit call being triggered to the firewall.
6. Create another rule2 and perform terraform apply.
7. Now the rule1 gets deleted and rule2 is present in firewall.

Important Factoids

No response

References

This is reopening same issue described here - #23283