Ambiguous Exit Codes on Timeout

“az resource wait --custom returns exit code 0 when condition times out ### Describe the bug `az resource wait --custom` honors `--timeout`, but when the custom condition remains false for the entire timeout, the command prints `{}` and exits with code `0`. A true condition also exits with code `0`, so scripts and CI systems cannot distinguish condition satisfaction from timeout. The current `dev` source still contains the apparent root cause in `src/azure-cli-core/azure/cli/core/commands/command_operation.py`: `WaitCommandOperation.wait` returns a `CLIError` object on timeout instead of raising it. ```python progress_indicator.end() return CLIError('Wait operation timed-out after {} seconds'.format(timeout)) ``` This appears to affect generic Azure CLI wait commands, not only this resource type. ### Related command ```bash az resource wait --ids "<RESOURCE_ID>" --custom "properties.connectivityStatus=='Connecting'" --interval 5 --timeout 30 ``` ### Errors No error is emitted. The timeout result is: ```text {} exit code: 0 elapsed time: 33 seconds ``` ### Issue script and debug output Given an existing ARM resource whose `properties.connectivityStatus` is `Connected`: ```bash az resource show \ --ids "<RESOURCE_ID>" \ --query "{connectivityStatus:properties.connectivityStatus,provisioningState:properties.provisioningState}" \ -o json ``` Result: ```json { "connectivityStatus": "Connected", "provisioningState": "Succeeded" } ``` Positive control - true condition: ```bash az resource wait \ --ids "<RESOURCE_ID>" \ --custom "properties.connectivityStatus=='Connected'" \ --interval 15 \ --timeout 900 echo $? ``` Observed: ```text exit code: 0 elapsed time: 1.6 seconds ``` Negative test - false condition: ```bash start_time=$(date +%s) az resource wait \ --ids "<RESOURCE_ID>" \ --custom "properties.connectivityStatus=='Connecting'" \ --interval 5 \ --timeout 30 wait_exit_code=$? elapsed_seconds=$(($(date +%s) - start_time)) printf 'wait_exit_code=%s\nelapsed_seconds=%s\n' \ "$wait_exit_code" \ "$elapsed_seconds" ``` Observed: ```text {} wait_exit_code=0 elapsed_seconds=33 ``` Impossible-condition test: ```bash start_time=$(date +%s) output=$(az resource wait \ --ids "<RESOURCE_ID>" \ --custom "properties.connectivityStatus=='DefinitelyNotAStatus'" \ --interval 2 \ --timeout 10 2>&1) wait_exit_code=$? elapsed_seconds=$(($(date +%s) - start_time)) printf 'output=%s\nwait_exit_code=%s\nelapsed_seconds=%s\n' \ "$output" \ "$wait_exit_code" \ "$elapsed_seconds" ``` Observed: ```text output={} wait_exit_code=0 elapsed_seconds=12 ``` The impossible value rules out a transient state transition. No resource identifiers or debug output are included because they are unnecessary for reproduction. ### Expected behavior When `--timeout` expires before `--custom` evaluates to true, the command should: 1. Exit with a nonzero code. 2. Emit `Wait operation timed-out after <seconds> seconds` or another clear timeout error. 3. Remain distinguishable from successful condition satisfaction in automation. ### Environment Summary ```text Azure CLI: 2.89.1 azure-cli-core: 2.89.1 azure-cli-telemetry: 1.1.0 OS: Linux 6.17.0-1022-azure, x86_64 Shell: GNU bash 5.2.21 Resource type: Microsoft.Kubernetes/connectedClusters ``` The same timeout code path remains present on current `dev` commit `b92a89e7781c11a5ee8437a84ef4b8fd9edab4f0` (August 27, 2026). ### Additional context Related but not duplicate: - #28523 reports another command returning exit code `0` on failure. - #32961 reports a custom JMESPath condition returning immediately, rather than timeout being returned as success. ”