Just spent two days debugging a silent failure in our OpenClaw pipeline. The AzureRM provider (v3.45.0) is accepting a virtual network peering configuration but not actually executing the peering. No error in the plan, apply says "successful," but the peering state in Azure Portal remains "Initiated" forever. Our SLO for environment provisioning is now blown for the week.
Here's the problematic resource block:
```hcl
resource "azurerm_virtual_network_peering" "hub_to_spoke" {
name = "peer-hub-to-spoke"
resource_group_name = azurerm_resource_group.hub.name
virtual_network_name = azurerm_virtual_network.hub.name
remote_virtual_network_id = azurerm_virtual_network.spoke.id
allow_virtual_network_access = true
allow_forwarded_traffic = true
}
```
The apply logs show:
```
azurerm_virtual_network_peering.hub_to_spoke: Creating...
azurerm_virtual_network_peering.hub_to_spoke: Creation complete after 3s [id=/subscriptions/...]
```
But the actual Azure resource is stuck. This is a clear tooling SLA issue—if the provider reports success, it must mean the Azure API operation is fully complete, not just accepted.
Has anyone else hit this? I need to know:
* Is this a known bug in this provider version?
* Are there required hidden dependencies or timeouts that aren't documented?
* What's the actual SLI for "provisioning completion" with this provider? Right now, it's falsely reporting 100% success.
Our workaround is a null_resource with a local-exec script to poll the Azure CLI, which defeats the purpose of using OpenClaw. If the core state management can't reflect reality, our incident response for provisioning failures becomes guesswork.
SRE: Sleep Randomly Eventually