Describe the bug
When az vm create fails a deployment (e.g. SkuNotAvailable due to capacity restrictions, or QuotaExceeded), the CLI's own error-handling path throws a second, unrelated exception while trying to format the first one, so the top-level failure the user sees is a confusing internal traceback (RuntimeError: The content for this response was already consumed) instead of a clean error message. The real Azure error is still present deeper in the traceback text, but it's buried under CLI-internal noise.
Related command
az vm create \
--resource-group <rg> \
--name <vm> \
--image Win2022Datacenter \
--size Standard_B2s \
--admin-username <user> \
--admin-password <redacted> \
--public-ip-address "" \
--storage-sku StandardSSD_LRS
This reproduced consistently across multiple regions (westeurope, northeurope, eastus) and multiple VM sizes (Standard_B2s, Standard_B2ms, Standard_D2s_v3, Standard_D2s_v5, Standard_B1s) whenever the underlying deployment failed - both for SkuNotAvailable (capacity restriction) and QuotaExceeded failures.
Errors
Traceback (most recent call last):
File "/opt/az/lib/python3.14/site-packages/azure/cli/core/commands/arm.py", line 109, in handle_template_based_exception
raise CLIError(ex.inner_exception.error.message)
^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'error'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/az/lib/python3.14/site-packages/knack/cli.py", line 233, in invoke
cmd_result = self.invocation.execute(args)
File "/opt/az/lib/python3.14/site-packages/azure/cli/core/commands/__init__.py", line 677, in execute
raise ex
File "/opt/az/lib/python3.14/site-packages/azure/cli/core/commands/__init__.py", line 820, in _run_jobs_serially
results.append(self._run_job(expanded_arg, cmd_copy))
File "/opt/az/lib/python3.14/site-packages/azure/cli/core/commands/__init__.py", line 812, in _run_job
return cmd_copy.exception_handler(ex)
File "/opt/az/lib/python3.14/site-packages/azure/cli/core/commands/arm.py", line 112, in handle_template_based_exception
raise_subdivision_deployment_error(ex.response.internal_response.text, ex.error.code if ex.error else None)
File "/opt/az/lib/python3.14/site-packages/requests/models.py", line 928, in text
if not self.content:
File "/opt/az/lib/python3.14/site-packages/requests/models.py", line 899, in content
raise RuntimeError("The content for this response was already consumed")
RuntimeError: The content for this response was already consumed
The genuine deployment error (e.g.):
(SkuNotAvailable) The requested VM size for resource 'Following SKUs have failed for Capacity Restrictions: Standard_B2s' is currently not available in location 'eastus'. Please try another size or deploy to a different location or different zone.
or
Code: QuotaExceeded
Message: Operation could not be completed as it results in exceeding approved standardDSv5Family Cores quota. ... Current Limit: 0, Current Usage: 0, Additional Required: 2 ...
...is present in the exception text at that point, but raise_subdivision_deployment_error tries to read ex.response.internal_response.text a second time after requests has already consumed the stream, so formatting it throws RuntimeError instead of surfacing the message.
Expected behavior
A failed deployment (capacity, quota, or otherwise) should surface a single, clean error message from the actual Azure response - not a RuntimeError about an already-consumed HTTP response body masking it.
Environment summary
{
"azure-cli": "2.89.1",
"azure-cli-core": "2.89.1",
"azure-cli-telemetry": "1.1.0"
}
- OS: Linux (Ubuntu-based), Python 3.14
- Reproduced with both
Microsoft.Compute/virtualMachines classic az vm create deployments across three regions and five VM sizes.
Describe the bug
When
az vm createfails a deployment (e.g.SkuNotAvailabledue to capacity restrictions, orQuotaExceeded), the CLI's own error-handling path throws a second, unrelated exception while trying to format the first one, so the top-level failure the user sees is a confusing internal traceback (RuntimeError: The content for this response was already consumed) instead of a clean error message. The real Azure error is still present deeper in the traceback text, but it's buried under CLI-internal noise.Related command
This reproduced consistently across multiple regions (westeurope, northeurope, eastus) and multiple VM sizes (Standard_B2s, Standard_B2ms, Standard_D2s_v3, Standard_D2s_v5, Standard_B1s) whenever the underlying deployment failed - both for
SkuNotAvailable(capacity restriction) andQuotaExceededfailures.Errors
The genuine deployment error (e.g.):
or
...is present in the exception text at that point, but
raise_subdivision_deployment_errortries to readex.response.internal_response.texta second time afterrequestshas already consumed the stream, so formatting it throwsRuntimeErrorinstead of surfacing the message.Expected behavior
A failed deployment (capacity, quota, or otherwise) should surface a single, clean error message from the actual Azure response - not a
RuntimeErrorabout an already-consumed HTTP response body masking it.Environment summary
Microsoft.Compute/virtualMachinesclassicaz vm createdeployments across three regions and five VM sizes.