`az webapp` and unexpected results when defining slot via id instead of param

[frankvaneykelen-work]

One of our teams used this command to set app settings on the staging slot:

az webapp config appsettings set `
    --ids /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/foo-rg/providers/Microsoft.Web/sites/foo-app/slots/staging `
    --settings expectedslot=staging actualslot=production

They expected this command to add the settings to the staging slot (as set via the --ids param), but instead they were added to the production slot. This let me to search for a command that could be parameterized to work both for test environments (that directly deploy to the production slot) and production (that deploys to a staging slot), but I came back empty handed.

This what I would like to do:

$slotName = "staging"
az webapp config appsettings set `
    --ids /subscriptions/[...]/resourceGroups/foo-rg/providers/Microsoft.Web/sites/foo-app `
    --slot $slotName  --settings [...]

# same command with different parameter value
$slotName = "production"
az webapp config appsettings set `
    --ids /subscriptions/[...]/resourceGroups/foo-rg/providers/Microsoft.Web/sites/foo-app `
    --slot $slotName  --settings [...]

The first command succeeds, but the last command fails with:

(ResourceNotFound) The Resource 'Microsoft.Web/sites/foo-app/slots/production' under resource group 'foo-rg' was not found. 
For more details please go to https://aka.ms/ARMResourceNotFoundFix

An alternative way via the --ids instead of the --slot also doesn't work:

$slotName = "staging"
az webapp config appsettings set `
    --ids /subscriptions/[...]/resourceGroups/foo-rg/providers/Microsoft.Web/sites/foo-app/slots/$slotName`
    --settings [...]

# same command with different slot in ids paramater value
$slotName = "production"
az webapp config appsettings set `
    --ids /subscriptions/[...]/resourceGroups/foo-rg/providers/Microsoft.Web/sites/foo-app/slots/$slotName`
    --slot $slotName  --settings [...]

Both commands succeed, but the first applies the appsettings to the production slot while $slotName = "staging"!

It tested the az webapp show and az webapp config appsettings set methods in the Azure Cloud Shell with all possible combinations and here are the results:

az webapp show inconsistencies

nr	slot in id	slot as param	result	as expected?
01	x	x	returns production	yes
02	x	production	ResourceNotFound	no (expected production)
03	x	staging	returns staging	yes
04	production	x	returns production	yes
05	production	production	ResourceNotFound	no (expected production)
06	production	staging	returns staging	no (expected conflict error)
07	staging	x	returns production	no (expected staging)
08	staging	production	ResourceNotFound	no (expected conflict error)
09	staging	staging	returns staging	yes

az webapp config appsettings set inconsistencies

	slot in id	slot as param	result	as expected?
10	x	x	adds to production slot	yes
11	x	production	ResourceNotFound	no (expected production)
12	x	staging	adds to staging slot	yes
13	production	x	adds to production slot	yes
14	production	production	ResourceNotFound	no (expected production)
15	production	staging	adds to staging slot	no (expected conflict error)
16	staging	x	adds to production (!) slot	no (expected staging)
17	staging	production	ResourceNotFound	yes
18	staging	staging	adds to staging slot	yes

I would like it if # 02 and # 11 would be fixed so that passing 'production' as a --slot param without a slot in de --ids would find the 'production' slot.

The other inconsistencies are harder to fix without introducing breaking changes.

Or am I missing something, and is this as intended?

[yonzhan]

Thank you for opening this issue, we will look into it.

[frankvaneykelen-work]

I am encountering a similar issue with az webapp deployment slot list. According to the docs it "Lists all deployment slots", but it actually only returns the staging slot, while I would expect it to return the same two slots as are shown under "Deployment Slots" of my App Service in the Azure Portal, like:

foobar-app PRODUCTION	
foobar-app-staging

A post on Stackoverflow by @juunas suggested this as a probable cause:

One thing to note is that Production is technically not a slot, it is the main App Service. That could be why you get a resource not found.

If that is the case it is my opinion that it would have been better when deployment slot list would have followed the convention that has been around forever in the Azure Portal, instead of taking a narrow semantic route and disqualifying the production slot as being an actual slot. No-one has ever said: "Let's swap the staging slot with the main app service", you swap the production and staging slots. After the swap, the staging slot is not named "former main app service" after all either.

[frankvaneykelen-work]

And some more context: I am struggling with this while refactoring Azure PowerShell to AZ CLI. In the former these commands work as expected:

Get-AzWebAppSlot -ResourceGroupName "Default-Web-WestUS" -Name "WebAppStandard" -Slot "Production"
Get-AzWebAppSlot -ResourceGroupName "Default-Web-WestUS" -Name "WebAppStandard" -Slot "Staging"

[frankvaneykelen-work]

This issues forces me to make my code a lot less DRY. I was expecting I could do this:

foreach ($slotName in @("staging", "production")) {
	$slot = (az webapp show --name $AppServiceName --resource-group $ResourceGroupName --slot $slotName | ConvertFrom-Json) # this fails for "production"
	# do stuff with $slot
}

but I need to do this:

$stagingSlot = (az webapp show --name $AppServiceName --resource-group $ResourceGroupName --slot 'staging' | ConvertFrom-Json)
# do stuff with $stagingSlot

$productionSlot = (az webapp show --name $AppServiceName --resource-group $ResourceGroupName | ConvertFrom-Json)
# do stuff with $productionSlot

[frankvaneykelen-work]

Just noticed that az webapp deployment slot swap does behave as I expect it to do because the --target-slot param defaults to 'production'!

[frankvaneykelen-work]

Did your looking into this yield anything?

[beliven-daniele-sarnari]

Same here +1