Platform gap: orphaned serviceAssociationLink (legionservicelink) has no customer-side recovery path — blocks subnet/VNET deletion permanently

This is less a "how do I fix my resource" question and more a report of a platform gap: once a serviceAssociationLink is orphaned, there appears to be no self-service or Basic-support-tier path to recover it — even though the link references a resource type (Microsoft.App/environments) that no longer exists anywhere in the subscription.

The recovery I am seeking is to delete a now redundant VNET subnet which the platform is blocking

Environment:

• Subscription: REDACTED
• Resource group: meter-data-rg
• VNET: meter-data-wireguard-vnet (created 2025-11-11)
• Subnet: function-integration-subnet (10.0.3.0/27)
• Region: UK South

Background / likely cause:

The design intent was a Flex Consumption Azure Function performing a short daily batch job

(~1 hour), reaching a serverless Azure SQL logical server over a private endpoint, with the subnet also fronting a WireGuard VM for admin access — all to avoid residual compute costs outside the daily window. This requires regional VNet integration from the Function App into the subnet, which is what creates the Microsoft.App/environments delegation and the legionservicelink association.

At some point during iteration the Function App that originally claimed this subnet was renamed, recreated, or deleted (my notes from that period don't reference a resource by the name currently in the resource group, meter-data-function-standard) — but the subnet's service association link was never released by the platform.

Current state confirmed via Azure CLI:

• az containerapp env list → empty array. No Container Apps environment exists anywhere in this subscription.
• Neither Function App in the resource group has an active VNet integration (az functionapp vnet-integration list → empty; virtualNetworkSubnetId → null on both). Neither is currently configured for Flex Consumption (functionAppConfig is null on both).
• 90-day activity log shows no Microsoft.App/* create or delete events, and no Microsoft.App/managedEnvironments deployment ever appears in this resource group's deployment history (link predates the 90-day retention window).

Error when deleting the subnet or VNET:

InUseSubnetCannotBeDeleted: Subnet function-integration-subnet is in use by

.../serviceAssociationLinks/legionservicelink and cannot be deleted.

Self-service dead end:

Removing the subnet delegation fails with:

SubnetMissingRequiredDelegation: ...those delegations are either missing or getting deleted from subnet.

So the delegation can't be removed while the link references it, and the link can't be removed without the delegation

— a lock with no customer-side exit. The Azure Portal's "Cannot delete VNET because of other resources" self-help diagnostic just points back to generic docs on removing delegations/peerings/gateways, none of which apply here since nothing is actually attached. And this subscription's Basic support tier doesn't offer a path to open an actual technical ticket for a platform-side issue like this — self-help is the only option offered, and it doesn't cover "the link is stale."

Ask: could someone confirm whether there's any customer-facing mechanism to clear an orphaned serviceAssociationLink, or whether this genuinely requires backend/engineering intervention every time it happens? If the latter, that seems worth flagging as a gap — plenty of people hit this exact error (see the many similar threads), and today's guidance uniformly assumes an owning resource still exists to delete.

Note that this is not a live or production system and no work done for the design since Nov-2025. I'm trying to delete unused resources now but can't

Happy to provide any further diagnostics.