Source: Azure/azure-cli#33835 (by Byron Tardif (@btardif))
Affected extension: webapp (src/webapp/)

<<UNTRUSTED:issue-33835>>

Issue #33835 (by Byron Tardif (@btardif))

Title

az webapp create ignores siteConfigPropertiesDictionary from the selected App Service stack

Body

Describe the bug

az webapp create --runtime resolves the selected runtime but does not apply the stack-specific site configuration supplied by the App Service stacks API in siteConfigPropertiesDictionary.

The current observable failure is Windows Node 24. Its stack metadata includes:

''' json
{
"siteConfigPropertiesDictionary": {
"use32BitWorkerProcess": false
}
}
'''

Node 24 is 64-bit only, but an app created with --runtime "NODE:24LTS" has use32BitWorkerProcess: true. A Node 24 probe then fails with HTTP 500. Changing only this property to false allows the same probe to run successfully as Node 24 x64.

This should not be fixed with a Node 24-specific or Windows-only condition. The stacks API is the source of truth for runtime-specific site configuration on both Windows and Linux. Upcoming runtimes, including .NET 11 on Windows, will also require use32BitWorkerProcess: false, while Linux stacks may use the dictionary for other platform-appropriate settings. Every consumer of the stacks API should honor these properties generically so that adding or changing a stack does not require another Azure CLI release or runtime-specific branch.

Related command

''' text
az webapp create
'''

Related inspection and workaround commands:

''' text
az webapp list-runtimes
az webapp config show
az webapp config set --use-32bit-worker-process false
'''

Errors

The create command succeeds, but the resulting app is configured incorrectly:

''' json
{
"nodeVersion": "",
"use32BitWorkerProcess": true,
"windowsFxVersion": null
}
'''

After deploying a no-dependency Node probe:

''' text
GET https://.azurewebsites.net/
HTTP 500

'''

The identical probe on an otherwise identical app where only use32BitWorkerProcess is set to false returns:

''' json
{
"nodeVersion": "v24.18.0",
"architecture": "x64",
"platform": "win32"
}
'''

Issue script & Debug output

The following reproduces the configuration defect on a currently selected subscription. App names must be globally unique.

''' powershell
$location = "eastus2"
$resourceGroup = "node24-cli-repro"
$planName = "node24-cli-repro-plan"
$appName = "node24-cli-repro-"

az group create --name $resourceGroup
--location $location

az appservice plan create --resource-group $resourceGroup
--name $planName --location $location
--sku P0v3 `
--is-linux false

az webapp list-runtimes --os-type windows
--query "[?config=='NODE|24LTS']"

az webapp create --resource-group $resourceGroup
--plan $planName --name $appName
--runtime "NODE:24LTS" `
--debug

az webapp config show --resource-group $resourceGroup
--name $appName `
--query "{nodeVersion:nodeVersion, windowsFxVersion:windowsFxVersion, use32BitWorkerProcess:use32BitWorkerProcess}"
'''

Runtime discovery correctly returns Node 24:

''' json
[
{
"config": "NODE|24LTS",
"os": "Windows",
"runtime": "Node",
"version": "24.0 LTS"
}
]
'''

Relevant sanitized --debug output:

''' text
Will set appsetting {'name': 'WEBSITE_NODE_DEFAULT_VERSION', 'value': '~24'}

PUT .../providers/Microsoft.Web/sites/?api-version=2025-05-01
Request body:
{
"properties": {
"siteConfig": {
"appSettings": [
{
"name": "WEBSITE_NODE_DEFAULT_VERSION",
"value": "~24"
}
],
"alwaysOn": true
},
"serverFarmId": ""
}
}

PUT .../providers/Microsoft.Web/sites//config/metadata?api-version=2025-05-01
Request body:
{
"properties": {
"CURRENT_STACK": "node"
}
}
'''

Neither request applies use32BitWorkerProcess: false. The resulting value is true:

''' json
{
"nodeVersion": "",
"use32BitWorkerProcess": true,
"windowsFxVersion": null
}
'''

The workaround is:

''' powershell
az webapp config set --resource-group $resourceGroup
--name $appName `
--use-32bit-worker-process false
'''

Expected behavior

When --runtime selects a Windows or Linux stack whose stacks API entry contains siteConfigPropertiesDictionary, az webapp create should merge those properties into the siteConfig sent to ARM.

For Windows Node 24, the initial create payload should therefore include:

''' json
{
"properties": {
"siteConfig": {
"use32BitWorkerProcess": false
}
}
}
'''

The implementation should be generalized:

1. Resolve the selected runtime's OS-specific stacks API entry.
2. Apply the valid siteConfigPropertiesDictionary entries to the create payload using the SiteConfig schema.
3. Do not hard-code an operating system, runtime name, or version such as Windows, NODE|24LTS, or .NET 11.
4. Preserve current defaults when the dictionary or a property is absent.
5. Give an explicit caller-supplied value precedence if az webapp create supports an override for the same property.

Regression coverage should verify that:

• Windows Node 24 is created with use32BitWorkerProcess == false and can run an x64 probe.
• Another stack carrying the same metadata receives the same setting without a runtime-specific code path. This should cover the upcoming .NET 11 requirement when that stack is available.
• A Linux stack or test fixture carrying site configuration metadata receives its declared properties through the same generalized path.
• A stack without this metadata retains its existing behavior.
• Additional valid SiteConfig properties supplied by stack metadata use the same generalized path.

Environment Summary

''' text
azure-cli 2.88.0
azure-cli-core 2.88.0
azure-cli-telemetry 1.1.0

Python (Windows) 3.14.5
OS Windows 11
'''

The issue was reproduced on a Windows P0v3 App Service plan in East US 2. The plan reported kind: app and reserved: false.

Additional context

The CLI correctly maps NODE|24LTS to WEBSITE_NODE_DEFAULT_VERSION=~24 and writes CURRENT_STACK=node; the missing behavior is propagation of the selected stack's site configuration metadata.

The observed side-by-side test used the same plan and identical deployment package:

The generalized, OS-independent stacks metadata behavior is the requested fix. A Node 24-only or Windows-only workaround in az webapp create would leave the same defect for .NET 11, Linux stacks, and other future runtime requirements.

Comments

Comment by Yong Zhang (@yonzhan)

Thank you for opening this issue, we will look into it.
<<END:issue-33835>>