Closed rjschwei closed 6 years ago
Thank you @rjschwei for reporting this. I will take a look at the source of this error and review the error handling in the storage module.
We can capture re-interrupt the error message for individual command. However, this falls into a wider category regarding how unexpected exception is presented at the core level.
A similar issue occurred when resizing an Elastic Pool. e.g. the following invocation failed with a similar message as reported above:
az sql elastic-pool update --id "/subscriptions/xxxxx/resourceGroups/Our-RG/providers/Microsoft.Sql/servers/servername/elasticPools/server-pool" \
--dtu 200 --edition Standard
but the following succeeded:
az sql elastic-pool update --id "/subscriptions/xxxxx/resourceGroups/Our-RG/providers/Microsoft.Sql/servers/servername/elasticPools/server-pool" \
--dtu 200 --edition Standard --max-size 50GB --db-dtu-max 200
In this case, it was just a matter of adding the required options.
We added a generic exception handler to gracefully handle many exceptions. If there are individual cases that produce stack traces, please open new issues. Stack traces are considered bugs in all cases by CLI team.
When there are backend issues the az tool generates a traceback on the command line rather than a proper error message.
The implementation should catch the exception and produce a sensible error message for the user.
Environment summary
openSUSE Leap 42.3, installed from RPM packages
azure-cli-storage-2.0.16