Add firewall rules failing

[arteonprifti]

Description

When creating two servers and adding firewall rules to the nics, adding the firewall rules fails for one of the servers

Expected behavior

create server and add firewall rules

Environment

Terraform version:
0.15.5
Provider version:
5.2.2
OS:
Ubuntu 20.04

How to Reproduce

uploaded plan on the other ticket SDK-338

Error and Debug Output

added on the other ticket

module.proxy.ionoscloud_firewall.proxy_http_public["002"]: Still creating... [1m40s elapsed]
module.proxy.ionoscloud_firewall.proxy_http_public["002"]: Creation complete after 1m47s [id=d9be84ed-4d38-4758-833d-e9b031b14413]
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to module.proxy.ionoscloud_firewall.proxy_https_public["001"], provider "provider["registry.terraform.io/ionos-cloud/ionoscloud"]" produced an unexpected new value: Root resource was
│ present, but now absent.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to module.proxy.ionoscloud_firewall.proxy_starttls["001"], provider "provider["registry.terraform.io/ionos-cloud/ionoscloud"]" produced an unexpected new value: Root resource was
│ present, but now absent.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to module.proxy.ionoscloud_firewall.proxy_smtp["001"], provider "provider["registry.terraform.io/ionos-cloud/ionoscloud"]" produced an unexpected new value: Root resource was present,
│ but now absent.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to module.proxy.ionoscloud_firewall.proxy_http_public["001"], provider "provider["registry.terraform.io/ionos-cloud/ionoscloud"]" produced an unexpected new value: Root resource was
│ present, but now absent.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Additional Notes

running the plan again works

[mflorin]

We've managed to reproduce this issue only when using the customer's plan. With a "regular" straight forward firewall resource everything works as expected. We're currently working on identifying a root cause for this.

[mflorin]

The problem is related to adding a nic in the same time as adding a new firewall rule and is on the provisioner side.
We've logged an internal ticket with the provisioner for that.

[mflorin]

@arteonprifti - a quick workaround consists of separating the creation of nics from the creation of the firewall rules resources.
Probably that's why your depends_on hack worked - because it basically instructed the firewall resource to wait for the nic resource to be ready, thus preventing the nic and firewall requests being queued in the same time.

[mflorin]

Closing, since the issue is already fixed in the provisioner api, waiting to be released.