Application Gateway - Error creating rule: Either all or no rule should have the priority specified

Related command az network application-gateway rule create

Describe the bug Attempting to create a new rule produces the following error:

ERROR: (ApplicationGatewayRequestRoutingRulePartialPriorityDefined) Either all or no rule should have the priority specified.

The CLI command does not provide the --priority flag so the priority number should be automatically generated (all other rules in the AGW have a priority already set).

To Reproduce Execute the following command:

az network application-gateway rule create `
        --gateway-name test-gateway-name `
        --name test-rule-name `
        --resource-group test-rg-name `
        --http-listener test-listener-name `
        --http-settings test-httpsetting-name `
        --address-pool test-address-pool-name

Expected behavior The priority value should be automatically generated by the service when it is not provided in the command.

Environment summary The CLI command is being executed by a ubuntu-18.04 Azure DevOps work agent.

Additional context This has only recently started failing (last couple of days).

[necusjz]

Are you saying that it is intended to not have the same behaviour between az cli version 2.34 and 2.37 because of the service? I understand the change in the service part, what I am still confuse is why we have different response depending on our az cli version.

More specifically, the reason is 2.34 and 2.37 send requests based on different API versions:

• 2.34: https://github.com/Azure/azure-cli/blob/598673dae676ead1fee4f58afa8c127b67f41be6/src/azure-cli-core/azure/cli/core/profiles/_shared.py#L147
• 2.37: https://github.com/Azure/azure-cli/blob/913767e3d77868586cb50eab1053aef20a7aa010/src/azure-cli-core/azure/cli/core/profiles/_shared.py#L150

And, as I mentioned before, the breaking change is involved since ‘2021-08-01’.

[necusjz]

I confirm we are observing the same behavior. but it works for CUS region and doesn’t work for EUS2

It might be related to the deployment strategy, as you known, East US 2 is one of the canary regions. Let’s wait for the service team to jump in and provide us more information. : )