Azure / Azure/azure-cli-extensions
[containerapp] az containerapp update --scale-rule-name silently replaces all existing scale rules instead of upserting
- Dominant language
- Python
- Stars
- 454
- Forks
- 1.7k
- Avg merge
- 2d 19h
- Merged PRs (30d)
- 64
Description
### 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`](https://github.com/Azure/azure-cli-extensions/blob/main/src/containerapp/azext_containerapp/containerapp_decorator.py) (the `construct_payload` method of `ContainerAppUpdateDecorator`):
```python
# 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:
```bash
# 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: #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.
Contributor guide
Assessment
This issue has not been assessed yet.