Hey all! I have updated from Azure Classic (golang) v5.89 to Azure Classic (golang) v6.5.0 - but am getting this error when my azure virtual network attempts to switch provider. All my subnets have address prefixes set and have for a very long time. Any ideas on how to resolve the below? I think it relates to https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/guides/4.0-upgrade-guide#additional-properties-for[…]-virtual-network-resource the azurerm terraform provider change: ‘In addition to the new properties

address_prefix

has been replaced by

address_prefixes

to allow multiple CIDRs in both IPv4 and IPv6 notation. When upgrading to 4.0, users may receive a warning that the resource needs to be replaced, this should however just be an update in-place.’ but it the azure classic code it’s mapped to address_prefix? error: azurenetworkVirtualNetwork VNET): error: sdk-v2/provider2.go520 sdk.helper_schema: updating Virtual Network (Subscription: “SUB_ID” Resource Group Name: “RG” Virtual Network Name: “VNET”): performing CreateOrUpdate: unexpected status 400 (400 Bad Request) with error: NoAddressPrefixOrPoolProvided: Address prefix and ipam pool reference are both empty/null in request payload of resource /subscriptions/VNET/subnets/SUBNET. Please provide either address prefix or ipam pool reference.: provider=azurerm@6.5.0

Could you please open an issue in https://github.com/pulumi/pulumi-azure with a simple repro code? Based on a cursory look I don't see anything wrong with property mapping, so we'd have to repro and debug the error.

Thank you for taking a quick look! We found the issue, was stack related We had some older setup for subnets array within our stack output for our VirtualNetwork. After updating our stack to remove the reference within the VirtualNetwork outputs section the subnets were removed (red in SS). I think we had created these a long time ago and the output had contained these subnets since then. After cleanup it was able to run properly. Blurred out shot of the removal that worked for us within our stack