[containerapp] az containerapp update --scale-rule-name silently replaces all existing scale rules instead of upserting

[maaaaac]

Describe the bug

When using az containerapp update --scale-rule-name to add a new scale rule to a container app that already has existing rules, the existing rules appear to be removed. The command succeeds with no error or warning, but only the newly specified rule remains afterward.

We expected --scale-rule-name on update to upsert: adding the rule if it doesn't exist, or replacing it by name if it does, while preserving other existing rules. Instead, all previously configured rules seem to be replaced by a single new rule.

We traced this to what appears to be the relevant code in containerapp_decorator.py (the construct_payload method of ContainerAppUpdateDecorator):

# Line 328-330
# so we don't overwrite rules
if safe_get(self.new_containerapp, "properties", "template", "scale", "rules"):
    self.new_containerapp["properties"]["template"]["scale"].pop(["rules"])

# Line 331-332
scale_rule_type = self.get_argument_scale_rule_type()
if self.get_argument_scale_rule_name():
    # ... builds scale_rule_def from CLI args (lines 333-366) ...

    # Line 367-370
    if not scale_def:
        scale_def = ScaleModel
    scale_def["rules"] = [scale_rule_def]  # single-element list
    self.new_containerapp["properties"]["template"]["scale"]["rules"] = scale_def["rules"]

The new rule is placed in a single-element list that overwrites the entire rules array. We couldn't find a code path that reads or preserves existing rules during an update. If we're misreading the code or there's a different intended workflow for adding multiple rules via CLI, we'd appreciate guidance.

Related command

az containerapp update --scale-rule-name

Errors

No error output. The command exits successfully with no warnings, which makes this difficult to detect.

Issue script & Debug output

The --debug output does not surface any error. The update command completes successfully, reporting no issues. The only way to observe the bug is by checking the rules before and after:

# Before: app has http-rule
az containerapp show --name test-app -g my-rg \
  --query "properties.template.scale.rules[].name"
# ["http-rule"]

# Run update to add a second rule
az containerapp update --name test-app -g my-rg \
  --scale-rule-name my-custom-rule \
  --scale-rule-type azure-servicebus \
  --scale-rule-metadata queueName=my-queue namespace=my-ns messageCount=5 \
  --scale-rule-auth connection=my-secret

# After: only the new rule exists, http-rule is gone
az containerapp show --name test-app -g my-rg \
  --query "properties.template.scale.rules[].name"
# ["my-custom-rule"]

From what we can see, the new rule is placed in a single-element list that replaces the entire rules array. We didn't find a code path that merges with existing rules. This pattern appears to have been present since the file was created (June 28, 2023, commit 8f077299e5).

If there's a different intended way to add multiple scale rules via CLI (other than --yaml or az rest), we'd appreciate knowing, as the docs and --help text don't seem to cover this scenario.

Expected behavior

We expected --scale-rule-name on update to add the new rule alongside existing rules (or replace by name if a rule with the same name already exists), preserving rules with different names.

Environment Summary

azure-cli                         2.81.0
azure-cli-core                    2.81.0
azure-cli-telemetry               1.1.0

Python (Darwin) 3.13.x
macOS 24.6.0

Additional context

• Related: az containerapp update is not setting minreplicas to 0 #5391, similar theme of az containerapp update not applying scale config as expected
• Note: az containerapp show using older API versions may only return one rule even when multiple exist. Use az rest with api-version=2025-01-01 to see all rules, which further makes this difficult to notice.
• If the current behavior is intentional, it would be helpful to document it in the --help text and scaling docs, as the silent replacement is easy to miss in CI/CD pipelines.

[yonzhan]

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

[maaaaac]

Workaround

We worked around this by replacing az containerapp update --scale-rule-name with az rest --method PATCH, which lets you set all scale rules atomically in a single call:

az rest --method PATCH \
  --url "https://management.azure.com/subscriptions/<SUB_ID>/resourceGroups/<RG>/providers/Microsoft.App/containerApps/<APP_NAME>?api-version=2025-01-01" \
  --body '{
    "properties": {
      "template": {
        "scale": {
          "minReplicas": 1,
          "maxReplicas": 10,
          "rules": [
            {
              "name": "http-rule",
              "http": {
                "metadata": {
                  "concurrentRequests": "25"
                }
              }
            },
            {
              "name": "my-servicebus-rule",
              "custom": {
                "type": "azure-servicebus",
                "metadata": {
                  "topicName": "my-topic",
                  "subscriptionName": "my-sub",
                  "namespace": "my-namespace",
                  "messageCount": "5"
                },
                "auth": [
                  {
                    "secretRef": "my-connection-string-secret",
                    "triggerParameter": "connection"
                  }
                ]
              }
            }
          ]
        }
      }
    }
  }'

Notes:

• Requires api-version=2025-01-01 or later (2024-03-01 does not support cooldownPeriod/pollingInterval fields)
• The PATCH only updates the scale config; it does not touch env vars, secrets, ingress, or other settings
• az containerapp show using older API versions may only return one rule even when multiple exist. Use az rest --method GET with the same api-version=2025-01-01 to verify all rules are present