[webapp] az webapp create ignores siteConfigPropertiesDictionary from the selected App Service stack

[azure-client-tools-agent]

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:

Creation/configuration	use32BitWorkerProcess	Result
az webapp create --runtime "NODE:24LTS" with no post-create change	true	HTTP 500
Same create command, followed only by az webapp config set --use-32bit-worker-process false	false	HTTP 200, Node v24.18.0, x64, win32

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>>

[azure-client-tools-agent]

Bug Analysis

Root Cause

az webapp create --runtime resolves the selected runtime stack from the App Service stacks API but does not merge the stack's siteConfigPropertiesDictionary into the siteConfig sent in the ARM PUT request.

For Windows Node 24, the stacks API returns:

{"siteConfigPropertiesDictionary": {"use32BitWorkerProcess": false}}

But the create payload only includes appSettings (e.g. WEBSITE_NODE_DEFAULT_VERSION=~24) and CURRENT_STACK=node metadata — never the use32BitWorkerProcess: false the stack requires. The resulting app is configured with use32BitWorkerProcess: true, causing HTTP 500 for a 64-bit-only runtime.

Fix Required

In the webapp extension's az webapp create handler:

1. After resolving the runtime stack entry via the stacks API, check if the entry contains a siteConfigPropertiesDictionary.
2. Merge all valid SiteConfig properties from that dictionary into the siteConfig block of the ARM PUT request body.
3. Do not hard-code OS, runtime name, or version — use the dictionary generically.
4. Preserve existing defaults when the dictionary or a property is absent.
5. Give explicit caller-supplied values precedence over dictionary values if the same siteConfig property is also an az webapp create parameter.

Relevant code is likely in src/webapp/azext_webapp/custom.py or _params.py in the create_webapp function where siteConfig is built before the ARM call.

Tests

Add regression tests that verify:

• Windows Node 24 create results in use32BitWorkerProcess == false
• A stack without siteConfigPropertiesDictionary retains existing behavior
• Any valid SiteConfig property in the dictionary is applied generically

Environment

• azure-cli 2.88.0, Windows 11, Python 3.14.5
• Reproduced on Windows P0v3 App Service plan in East US 2

Use this EXACT PR title: [Webapp] Fix #10175: az webapp create: apply siteConfigPropertiesDictionary from stacks API to siteConfig on create

PR title & description format (required)

This repo enforces a PR format (guide). Please author the PR exactly as follows or CI's Check the Format of Pull Request Title and Content will fail.

Use this EXACT PR title (copy verbatim, do not reword):

[Webapp] Fix #10175: `az webapp create`: apply siteConfigPropertiesDictionary from stacks API to siteConfig on create

Keep the backticks around the command and the Fix #10175: prefix. You may only adjust the wording after the command (the final summary) if the fix changes; the [Webapp] prefix, issue link, and backticked command must stay.

Description — follow the PR template and fill in:

• Link the issue — start the Description with a closing keyword so the PR auto-links and closes it: Fixes #10175.
• Related command — the az ... command this affects.
• Description (mandatory) — why the bug happens, what you changed, and the resulting behavior.
• Testing Guide — example command(s) showing the fix works.
• History Notes — leave the title to drive the history note, or add extra lines in the same format (component in brackets + the command in backticks), e.g. [Webapp] `az <command>`: <note>.
• Keep the template checklist and tick the items you've satisfied.

---

Posted by agent-assist (autonomous bug-fix pipeline).

[yonzhan]

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