Restore-AzWebAppSnapshot fails when large number of resources exist (sometimes) #26268
Labels
bug
This issue requires a change to an existing behavior in the product in order to be resolved.
customer-reported
needs-triage
This is a new issue that needs to be triaged to the appropriate team.
Description
Restore-AzWebAppSnapshot can fail when a large number of resources exist in the subscription.
Restore-AzWebAppSnapshot calls the "resources" API which returns paginated results.
If the Web App of the Snapshot is not returned on the first "page" of results, the restore operation will fail with an InternalServerError
Note: a "filter" is passed to this API call, however, it appears that the Resources API is first retrieving all results, then only filtering using the first page.
I suspect the above as I have tested the API call using the Azure Resource Explorer (https://resources.azure.com/subscriptions/[subscription-guid-redacted]/resources)
We have 24 different apps and only have consistent issues restoring 5 of them with this call.
All 5 of the affected web apps do not appear on the first "page" of results in Azure Resource Explorer, while all working apps DO appear on the first page.
In addition, we have one web app that works some of the time.
Refreshing the results in Azure Resource Explorer shows that sometimes this app appears on the first page and sometimes it does not.
Note: In the debug output below you will see the call to the Resources API
https://management.azure.com/subscriptions/[redacted]/resources?$filter=resourceType eq 'Microsoft.Web/sites' and name eq '[redacted]'&api-version=2016-09-01
Observe it returns an empty array with a "nextLink"
Issue script & Debug output
Environment data
Module versions
Error output
The text was updated successfully, but these errors were encountered: