azurerm_postgresql_flexible_server isn't destroyed properly

[saveler]

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

1.5.6

AzureRM Provider Version

3.71.0

Affected Resource(s)/Data Source(s)

azurerm_postgresql_flexible_server

Terraform Configuration Files

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "example" {
  name     = "example-resources"
  location = "westeurope"
}

resource "azurerm_virtual_network" "example" {
  name                = "example-vn"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  address_space       = ["10.0.0.0/16"]
}

resource "azurerm_subnet" "example" {
  name                 = "example-sn"
  resource_group_name  = azurerm_resource_group.example.name
  virtual_network_name = azurerm_virtual_network.example.name
  address_prefixes     = ["10.0.2.0/24"]
  service_endpoints    = ["Microsoft.Storage"]
  delegation {
    name = "fs"
    service_delegation {
      name = "Microsoft.DBforMySQL/flexibleServers"
      actions = [
        "Microsoft.Network/virtualNetworks/subnets/join/action",
      ]
    }
  }
}

resource "azurerm_private_dns_zone" "example" {
  name                = "example.mysql.database.azure.com"
  resource_group_name = azurerm_resource_group.example.name
}

resource "azurerm_private_dns_zone_virtual_network_link" "example" {
  name                  = "exampleVnetZone.com"
  private_dns_zone_name = azurerm_private_dns_zone.example.name
  virtual_network_id    = azurerm_virtual_network.example.id
  resource_group_name   = azurerm_resource_group.example.name
}

resource "azurerm_mysql_flexible_server" "example" {
  name                   = "example-fs"
  resource_group_name    = azurerm_resource_group.example.name
  location               = azurerm_resource_group.example.location
  administrator_login    = "psqladmin"
  administrator_password = "H@Sh1CoR3!"
  backup_retention_days  = 7
  delegated_subnet_id    = azurerm_subnet.example.id
  private_dns_zone_id    = azurerm_private_dns_zone.example.id
  sku_name               = "GP_Standard_D2ds_v4"

  depends_on = [azurerm_private_dns_zone_virtual_network_link.example]
}

Debug Output/Panic Output

During destroy we get an error, that subnet can't be destroyed, because subnet is still in use:

`network.SubnetsClient#Delete: Failure sending request: StatusCode=400 -- Original Error: Code="InUseSubnetCannotBeDeleted" Message="Subnet postgresql-delegated-subnet is in use by /subscriptions/***/***/providers/Microsoft.Network/virtualNetworks/***/subnets/postgresql-delegated-subnet/serviceAssociationLinks/2cd8a112-71f3-87ff-b9e7-66c90073da3c-service-association-link and cannot be deleted. In order to delete the subnet, delete all the resources within the subnet. See aka.ms/deletesubnet." Details=[]`

Expected Behaviour

Terraform should destroy subnet only when deletion of Postgres Flexible server is completed

Actual Behaviour

This error appeared when we decided to update AzureRM version from 3.69.0 -> 3.71.0

In AzureRM v3.69.0 destruction of PSQL Flex takes around 2 mins 30 secs, after that terraform starts deleting virtual network subnet of PSQL

In AzureRM v3.71.0 destruction takes only 10-14 secs and Terraform starts deleting subnet and of course it can't be deleted because PSQL Flex server is still there and uses the subnet. (when terraform says that PSQL is deleted, I can see it for the next 2-3 mins in Azure Portal and PSQL state is "Updating"). It means that azurerm provider decides that resources is deleted even if it is not.

I have a feeling that this issue appeared after one of the following changes in provider:

• dependencies: updating to v0.20230815.1165905 of github.com/hashicorp/go-azure-sdk (dependencies: updating to v0.20230815.1165905 of github.com/hashicorp/go-azure-sdk #22981)
• postgresql: updating to use the base layer from hashicorp/go-azure-sdk rather than Azure/go-autorest (dependencies: updating to v0.20230810.1125717 of github.com/hashicorp/go-azure-sdk #22874)

Steps to Reproduce

No response

Important Factoids

No response

References

No response

[neil-yechenwei]

Thanks for raising this issue. Seems azurerm_private_dns_zone_virtual_network_link missed the dependency declaration of azurerm_subnet. Below is an example and it works fine on my local.

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "test" {
  name     = "acctestpostgresqlfstest01"
  location = "westeurope"
}

resource "azurerm_virtual_network" "test" {
  name                = "acctestvnettest01"
  location            = azurerm_resource_group.test.location
  resource_group_name = azurerm_resource_group.test.name
  address_space       = ["10.0.0.0/16"]
}

resource "azurerm_subnet" "test" {
  name                 = "acctestsubnettest01"
  resource_group_name  = azurerm_resource_group.test.name
  virtual_network_name = azurerm_virtual_network.test.name
  address_prefixes     = ["10.0.2.0/24"]
  service_endpoints    = ["Microsoft.Storage"]

  delegation {
    name = "fs"
    service_delegation {
      name = "Microsoft.DBforPostgreSQL/flexibleServers"
      actions = [
        "Microsoft.Network/virtualNetworks/subnets/join/action",
      ]
    }
  }
}

resource "azurerm_private_dns_zone" "test" {
  name                = "acctest01.postgres.database.azure.com"
  resource_group_name = azurerm_resource_group.test.name
}

resource "azurerm_private_dns_zone_virtual_network_link" "test" {
  name                  = "acctestVnetZonetest01.com"
  private_dns_zone_name = azurerm_private_dns_zone.test.name
  virtual_network_id    = azurerm_virtual_network.test.id
  resource_group_name   = azurerm_resource_group.test.name

  depends_on = [azurerm_subnet.test]
}

resource "azurerm_postgresql_flexible_server" "test" {
  name                   = "acctestpostgresqlfstest01"
  resource_group_name    = azurerm_resource_group.test.name
  location               = azurerm_resource_group.test.location
  administrator_login    = "psqladmin"
  administrator_password = "A@Dh1BoR3!"
  backup_retention_days  = 7
  delegated_subnet_id    = azurerm_subnet.test.id
  private_dns_zone_id    = azurerm_private_dns_zone.test.id
  sku_name               = "GP_Standard_D2ds_v4"
  version                = "15"
  storage_mb             = 32768

  depends_on = [azurerm_private_dns_zone_virtual_network_link.test]
}

[saveler]

Hello @neil-yechenwei

What version of Azurerm provider do you use?

I still do not believe that it can be an issue, because Private DNS zone is not linked to subnet anyhow, it is linked to azure VNET. It is why it is not related to issue during destruction of subnet.
Maybe adding this dependency solves the issue, because it takes additional time to destroy this link and during this time PSQL is removed completely, but initial problem is that Terraform thinks that PSQL Flex server is destroyed when it is not. (we can see that in Azure Portal, even when terraform says that it has been destroyed)

We even can use a workaround to fix this issue on our side, for example by adding additional resource that will make a delay between PSQL destruction and destruction of subnet. But it will be a workaround, not a fix of initial bug in AzureRM provider

[saveler]

Hello @rcskosir !
I see that you added label "bug".
Have you already verified that it is a bug? Is there any ETA? We would like to get fix as soon as possible!

Thank you!

[amorphina]

Terraform version 1.9 and azurerm version 3.109.0 issue is still present.

[rtrigo-opengov]

Same here, in our case we have a module for the postgres server and the subnet but the vnet, dns zone and link are created outside the module, so setting that kind of dependency makes no sense. This worked fine before, we got this issue after updating azurerm from v3.69.0 to v3.109.0