cloudstack_port_forward always returns error (but really succeeds)

[bhouse-nexthop]

When creating a port forward I see:

Terraform will perform the following actions:

  # cloudstack_port_forward.bastion will be created
  + resource "cloudstack_port_forward" "bastion" {
      + id            = (known after apply)
      + ip_address_id = "02aae2fe-ae43-4030-8123-8967931fd7e1"
      + managed       = false

      + forward {
          + private_end_port   = (known after apply)
          + private_port       = 22
          + protocol           = "tcp"
          + public_end_port    = (known after apply)
          + public_port        = 5022
          + uuid               = (known after apply)
          + virtual_machine_id = "bebcac94-65f5-4c73-8586-e6e860bcc17e"
            # (1 unchanged attribute hidden)
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

cloudstack_port_forward.bastion: Creating...
cloudstack_port_forward.bastion: Still creating... [00m10s elapsed]
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to cloudstack_port_forward.bastion, provider "provider[\"registry.terraform.io/cloudstack/cloudstack\"]" produced an unexpected new value: Root object was present, but now
│ absent.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵

Though the operation actually succeeds. On subsequent runs I get:

Terraform will perform the following actions:

  # cloudstack_port_forward.bastion will be created
  + resource "cloudstack_port_forward" "bastion" {
      + id            = (known after apply)
      + ip_address_id = "02aae2fe-ae43-4030-8123-8967931fd7e1"
      + managed       = false

      + forward {
          + private_end_port   = (known after apply)
          + private_port       = 22
          + protocol           = "tcp"
          + public_end_port    = (known after apply)
          + public_port        = 5022
          + uuid               = (known after apply)
          + virtual_machine_id = "bebcac94-65f5-4c73-8586-e6e860bcc17e"
            # (1 unchanged attribute hidden)
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

cloudstack_port_forward.bastion: Creating...
╷
│ Error: 1 error occurred:
│ 	* CloudStack API error 537 (CSExceptionErrorCode: 4360): The range specified, 5022-5022, conflicts with rule FirewallRule {"id":251,"networkId":219,"purpose":"PortForwarding","state":"Active","uuid":"ae971788-f28c-4e33-b3c1-dcae449bf91f"} which has 5022-5022
│
│
│
│   with cloudstack_port_forward.bastion,
│   on network_su.tf line 79, in resource "cloudstack_port_forward" "bastion":
│   79: resource "cloudstack_port_forward" "bastion" {
│

which makes sense as the prior attempt really succeeded.

I'm running Cloudstack 4.22.0.0 with the 0.6.0 cloudstack terraform provider with terraform v1.13.3. This also happened on the 0.5.0 cloudstack provider.

[bhouse-nexthop]

I should also mention this same thing happens in multiple independent environments with different generations of hardware, etc

[bhouse-nexthop]

root cause was I wasn't specifying 'project', which the cloudstack api doesn't have, but due to the way the lookups were working the provider was requiring it. PR #280 fixes this to not mandate project in this resource nor a few others.