Deployment of Azure Function fails with "There was an unexpected InternalServerError"

[plamber]

Issue Type: (mark with an x)

- [x] Bug report – please search for similar issues before submitting
- [ ] Feature request
- [ ] Documentation issue or request
- [ ] Regression (behavior that used to work and stopped in a new release)

Description:

When deploying an Azure Function Flex Consumption plan using Bicep in one of our subscriptions, the deployment fails with the error: "There was an unexpected InternalServerError."

• The provider "Microsoft.App" is registered.
• The deployment is being performed in the North Europe region.
• The same scripts run successfully on other subscriptions without issues.

Minimal Steps to Reproduce:

Unfortunately, I don't have specific reproduction steps, but I can provide the error details and the affected subscription ID.

• Subscription ID: 7b87b53d-3bb2-4674-b862-0061cc2e5222
• 9/13/2024, 6:56:57 AM

  Error: There was an unexpected InternalServerError. Please try again later.  
  x-ms-correlation-request-id: 48b253a1-2bca-416e-8dc6-2487cea20a34  
  (Code: InternalServerError)

Expected Behavior:

• The error message should provide more detailed context about the issue.
• Deployment should complete without errors.

[nzthiago]

The exception I see is "A reference id is already registered with this subnet." This is another error message we will work to surface instead of InternalServerError. Are you using that subnet for any other purposes besides Flex Consumption?

[plamber]

Hi @nzthiago,

The Bicep script is being applied consistently across three different subscriptions, but only one of them is experiencing issues, while the other two work without problems.

To address your question:

• The network consists of three subnets:
  1. The first subnet hosts the Azure Function Storage Account and KeyVault.
  2. The second subnet is dedicated exclusively to the Azure Function.
  3. The third subnet contains two private links to storage accounts in a different network. From my understanding, this cross-network configuration shouldn't be causing issues.

As shown here, the service endpoints are associated with the KeyVault and Storage Account, but they reside in the first subnet.

Additionally, there are two other Azure Functions within this same subscription, deployed under the Consumption Plan, but in different regions and resource groups.

I’ve confirmed that the subnets are correctly assigned.

I attempted to delete all resources, but I'm encountering an issue with the virtual network. For some reason, I’m unable to delete it or modify the subnet that should have been connected. It appears that something went wrong during the initial provisioning, and now redeployment using the same names is no longer possible.

Failed to delete resource group rg-el-i-noti-core: Deletion of resource group 'rg-el-i-noti-core' failed as resources with identifiers 'Microsoft.Network/virtualNetworks/el-i-noti-vn-ne' could not be deleted. The provisioning state of the resource group will be rolled back. The tracking Id is '60639df6-dfb9-4dfc-9017-9eb5da7f9e1d'. Please check audit logs for more details. (Code: ResourceGroupDeletionBlocked) Subnet engines is in use by /subscriptions/7b87b53d-3bb2-4674-b862-0061cc2e5222/resourceGroups/rg-el-i-noti-core/providers/Microsoft.Network/virtualNetworks/el-i-noti-vn-ne/subnets/engines/serviceAssociationLinks/legionservicelink and cannot be deleted. In order to delete the subnet, delete all the resources within the subnet. See aka.ms/deletesubnet. (Code: InUseSubnetCannotBeDeleted, Target: /subscriptions/7b87b53d-3bb2-4674-b862-0061cc2e5222/resourceGroups/rg-el-i-noti-core/providers/Microsoft.Network/virtualNetworks/el-i-noti-vn-ne)

This is the information of the subnet

{
  "addressPrefix": "201.0.4.0/22",
  "delegations": [
    {
      "actions": [
        "Microsoft.Network/virtualNetworks/subnets/join/action"
      ],
      "etag": "W/\"067913f2-89b9-4cba-983c-a3926855d1a2\"",
      "id": "/subscriptions/7b87b53d-3bb2-4674-b862-0061cc2e5222/resourceGroups/rg-el-i-noti-core/providers/Microsoft.Network/virtualNetworks/el-i-noti-vn-ne/subnets/engines/delegations/delegation",
      "name": "delegation",
      "provisioningState": "Succeeded",
      "resourceGroup": "rg-el-i-noti-core",
      "serviceName": "Microsoft.App/environments",
      "type": "Microsoft.Network/virtualNetworks/subnets/delegations"
    }
  ],
  "etag": "W/\"067913f2-89b9-4cba-983c-a3926855d1a2\"",
  "id": "/subscriptions/7b87b53d-3bb2-4674-b862-0061cc2e5222/resourceGroups/rg-el-i-noti-core/providers/Microsoft.Network/virtualNetworks/el-i-noti-vn-ne/subnets/engines",
  "name": "engines",
  "privateEndpointNetworkPolicies": "Disabled",
  "privateLinkServiceNetworkPolicies": "Enabled",
  "provisioningState": "Succeeded",
  "resourceGroup": "rg-el-i-noti-core",
  "serviceAssociationLinks": [
    {
      "allowDelete": false,
      "etag": "W/\"067913f2-89b9-4cba-983c-a3926855d1a2\"",
      "id": "/subscriptions/7b87b53d-3bb2-4674-b862-0061cc2e5222/resourceGroups/rg-el-i-noti-core/providers/Microsoft.Network/virtualNetworks/el-i-noti-vn-ne/subnets/engines/serviceAssociationLinks/legionservicelink",
      "link": "/subscriptions/7b87b53d-3bb2-4674-b862-0061cc2e5222/resourcegroups/rg-el-i-noti-core/virtualnetworks/el-i-noti-vn-ne/subnets/engines",
      "linkedResourceType": "Microsoft.App/environments",
      "locations": [],
      "name": "legionservicelink",
      "provisioningState": "Succeeded",
      "resourceGroup": "rg-el-i-noti-core",
      "type": "Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks"
    }
  ],
  "serviceEndpoints": [],
  "type": "Microsoft.Network/virtualNetworks/subnets"
}

Cheers

[nzthiago]

@plamber sorry for the delay in replying. Are you able to create a support ticket for this issue? We have identified that the VNet association with the app didn't get deleted correctly when the app was previously deleted and would like to investigate further.