[containerapp] az containerapp create --yaml injects null fields into PUT request body, causing HTTP 400 (System.Boolean conversion error) #9729

Describe the bug

When using az containerapp create --yaml <file>, the containerapp CLI extension serializes the
full internal model object and sends it as the HTTP PUT request body. All unset/optional fields
are included as null instead of being omitted.

This causes Azure Resource Manager (ARM) to fail during deserialization when it tries to convert
a null value into a non-nullable type such as System.Boolean. The result is an HTTP 400 error.

Key offending null field confirmed via --debug:

{
  "tags": null,
  "extendedLocation": null,
  "identity": null,
  "managedBy": null,
  "kind": null,
  "properties": {
    "configuration": {
      "secrets": null,
      "activeRevisionsMode": null,
      "ingress": {
        "fqdn": null,
        "transport": null,
        "traffic": null,
        "allowInsecure": null,        <- ARM tries to deserialize this as System.Boolean -> FAILS
        "ipSecurityRestrictions": null,
        "stickySessions": null,
        "clientCertificateMode": null,
        ...
      },
      "dapr": null,
      "runtime": null,
      ...
    },
    "template": {
      "revisionSuffix": null,
      "initContainers": null,
      "containers": [
        {
          "command": null,
          "args": null,
          "env": null,
          "volumeMounts": null,
          "probes": null
        }
      ],
      "volumes": null,
      "serviceBinds": null"
    },
    "workloadProfileName": null,
    ...
  }
}

az containerapp update --yaml works : The update command uses HTTP PATCH and sends
only a sparse/diff body (without null fields), which succeeds. In this case, update requires the
resource to already exist and cannot be used for initial creation.

This bug has been confirmed on both Global Azure (AzureCloud) and Azure China (AzureChinaCloud).

Related command

az containerapp create --name <app> --resource-group <rg> --yaml <path-to-yaml>

Errors

Bad Request({"type":"https://tools.ietf.org/html/rfc9110#section-15.5.1",
"title":"One or more validation errors occurred.",
"status":400,
"errors":{"$":["The JSON value could not be converted to System.Boolean.
Path: $ | LineNumber: 0 | BytePositionInLine: 4."]}})

Issue script & Debug output

Minimal reproduction YAML (capp-test.yaml):

location: eastus
name: capp-test
resourceGroup: my-rg
type: Microsoft.App/containerApps
properties:
  managedEnvironmentId: /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.App/managedEnvironments/<env>
  configuration:
    ingress:
      external: true
      targetPort: 80
  template:
    containers:
      - name: capp-test
        image: mcr.microsoft.com/k8se/quickstart:latest
        resources:
          cpu: 0.5
          memory: 1Gi
    scale:
      minReplicas: 1
      maxReplicas: 1

Reproduce:

az containerapp create --name capp-test --resource-group my-rg --yaml capp-test.yaml --debug

Debug log shows the PUT request body contains dozens of null fields, including
"allowInsecure": null, which ARM cannot deserialize as System.Boolean.

Expected behavior

The CLI extension should omit null/unset fields from the PUT request body (or use JSON merge
patch semantics), so that ARM only receives fields that are explicitly set in the YAML.

Workaround that works today: use az deployment group create --template-file xxx.bicep (Bicep
or ARM JSON), which does not have this serialization issue.

Environment Summary

az --version
azure-cli 2.84.0

core 2.84.0
telemetry 1.1.0

Extensions:
containerapp 1.3.0b4
resource-graph 2.1.1

Dependencies:
msal 1.35.0b1
azure-mgmt-resource 24.0.0

Python location 'C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe'
Config directory 'C:\Users\xxx.azure'
Extensions directory 'C:\Users\xxx.azure\cliextensions'

Python (Windows) 3.13.11 (tags/v3.13.11:6278944, Dec 5 2025, 16:17:02) [MSC v.1944 32 bit (Intel)]

Legal docs and information: aka.ms/AzureCliLegal

Your CLI is up-to-date.

Additional context

• az containerapp update --yaml (PATCH) works correctly because it sends a sparse body
• az deployment group create --template-file (Bicep/ARM JSON) works correctly
• The --yaml input flag is unique to az containerapp commands; other services
  (az vm, az aks, az deployment) do NOT support --yaml as an input format