Regression in azure-cli 2.77.0: 'az batch application package create' no longer updates existing version and fails with BlobAlreadyExists

[OGLara]

Hello Azure CLI Team,

I'm reporting what appears to be a regression or a breaking change in the behavior of the az batch application package create command starting with azure-cli version 2.77.0.

Description

In previous versions of the CLI (specifically tested with 2.76.*), running az batch application package create with a --version-name that already existed would successfully overwrite the package file in the underlying storage account. This allowed us to update application packages in place.

Since updating to version 2.77.0, the exact same command now fails with a BlobAlreadyExists error, preventing the update. This has broken our CI/CD pipelines, which relied on this behavior to deploy updates to static version tags like dev or latest.

Steps to Reproduce

1. Use azure-cli version 2.77.0.
2. Create an initial application package version:

   # Create version "my-version" with a first file
   az batch application package create --resource-group MyResourceGroup --account-name MyBatchAccount --application-name MyApp --version-name "my-version" --package-file "package-v1.zip"

3. Attempt to update the same package version with a new file:

   # In v2.76.* this would succeed. In v2.77.0 it fails.
   az batch application package create --resource-group MyResourceGroup --account-name MyBatchAccount --application-name MyApp --version-name "my-version" --package-file "package-v2.zip"

Expected Behavior

The command should successfully upload package-v2.zip, overwriting the existing blob for the my-version package, consistent with the behavior observed in azure-cli 2.76.*.

Actual Behavior

The command fails with the following error:

ERROR: The specified blob already exists.
RequestId:0e515875-b01e-001e-4370-21368c000000
Time:2025-09-09T10:00:48.3513309Z
ErrorCode:BlobAlreadyExists

Additional Context

This change forces us to adopt a "delete-then-create" workflow, which is less atomic and adds complexity to our deployment scripts. While we understand this might align with a stricter interpretation of the API, the previous behavior was extremely useful.

If this is the new intended behavior, please confirm. In that case, we would like to formally request a feature enhancement, such as an --overwrite flag, to restore the ability to update a package in a single, atomic command.

Thank you for your time and consideration.

Related command

az batch application package create

Errors

ERROR: The specified blob already exists.
RequestId:0e515875-b01e-001e-4370-21368c000000
Time:2025-09-09T10:00:48.3513309Z
ErrorCode:BlobAlreadyExists

Issue script & Debug output

DEBUG: cli.azure.cli.core.azclierror: Traceback (most recent call last):
File "/opt/az/lib/python3.13/site-packages/azure/cli/core/commands/init.py", line 703, in _run_job
result = cmd_copy(params)
File "/opt/az/lib/python3.13/site-packages/azure/cli/core/commands/init.py", line 336, in call
File "/opt/az/lib/python3.13/site-packages/azure/multiapi/storagev2/blob/v2022_11_02/_shared/response_handlers.py", line 189, in process_storage_error
exec("raise error from None") # pylint: disable=exec-used # nosec
~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
File "", line 1, in
File "/opt/az/lib/python3.13/site-packages/azure/multiapi/storagev2/blob/v2022_11_02/_upload_helpers.py", line 106, in upload_block_blob
response = client.upload(
body=data,
...<11 lines>...
legal_hold=legal_hold,
**kwargs)
File "/opt/az/lib/python3.13/site-packages/azure/core/tracing/decorator.py", line 119, in wrapper_use_tracer
return func(*args, **kwargs)
File "/opt/az/lib/python3.13/site-packages/azure/multiapi/storagev2/blob/v2022_11_02/_generated/operations/_block_blob_operations.py", line 852, in upload
map_error(status_code=response.status_code, response=response, error_map=error_map)
~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/az/lib/python3.13/site-packages/azure/core/exceptions.py", line 163, in map_error
raise error
azure.core.exceptions.ResourceExistsError: The specified blob already exists.
RequestId:550a63f5-a01e-0060-4682-21a6cb000000
Time:2025-09-09T12:10:19.3841319Z
ErrorCode:BlobAlreadyExists

Expected behavior

The command should successfully upload package-v2.zip, overwriting the existing blob for the my-version package, consistent with the behavior observed in azure-cli 2.76.*.

Environment Summary

azure-cli 2.77.0

core 2.77.0
telemetry 1.1.0

Extensions:
azure-devops 1.0.2

Dependencies:
msal 1.34.0b1
azure-mgmt-resource 23.3.0

Additional context

No response

[yonzhan]

Thank you for opening this issue, we will look into it.

[microsoft-github-policy-service]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @dpwatrous, @wiboris, @cRui861, @skapur12, @wanghoppe.

[github-actions]

Here are some similar issues that might help you. Please check if they can solve your problem.

• az storage blob upload can overwrite a blob without needing the --overwrite parameter in az cli version 2.33.1 , however in version 2.34.1 it requires the overwrite parameter. #21779

---

Possible solution (Extracted from existing issue, might be incorrect; please verify carefully)

Solution 1:

We have included this as a breaking change in 2.34.1 as we think it is dangerous to overwrite files silently. --overwrite needs to be specified to overwrite files. Sorry for the inconvenience.
https://docs.microsoft.com/en-us/cli/azure/storage/blob?view=azure-cli-latest#az-storage-blob-upload

Reference:

• az storage blob upload can overwrite a blob without needing the --overwrite parameter in az cli version 2.33.1 , however in version 2.34.1 it requires the overwrite parameter. #21779 (comment)

Solution 2:

To workaround this, I need to manually detect the az version, then issue 2 different commands, depending on the version, since the --overwrite option does not exist in az storage upload before 2.34.1. It's not optimal imo.

--overwrite should be true by default and when not specified, to ensure backward compatibility. If a user wants to ensure that its data can't be overwritten, it could specify --overwrite false.

Reference:

• az storage blob upload can overwrite a blob without needing the --overwrite parameter in az cli version 2.33.1 , however in version 2.34.1 it requires the overwrite parameter. #21779 (comment)

Solution 3:

To Add to above the I have noticed Running this in AzureCLIv2 Pipeline Task as ps inline script upload-batch runs fine with out using --overwrite on subsequent runs it throws an error and suggests to use --overwrite handle which takes away the error by --overwriting and not throwing error that blob already exists. Problem here is when I move into another environment with everything fixed. Script complaints about error unrecognised arguments -- overwrite.

I'm looking to find out if there is a work-around for this so that we can keep -- overwrite argument for subsequent runs and to exclude it for the first run on a new environment or blob container.

Reference:

• az storage blob upload can overwrite a blob without needing the --overwrite parameter in az cli version 2.33.1 , however in version 2.34.1 it requires the overwrite parameter. #21779 (comment)

Powered by issue-sentinel

[microsoft-github-policy-service]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @dpwatrous, @wiboris, @cRui861, @skapur12, @wanghoppe.

[Luther-Varys]

My issue in Devops - YAML:
The zip file was uploaded, but in the storage account it was an empty file, that contained just a string with the file path! Very odd!

I've downgraded to 2.76.0 and it works as usual.

Seems 2.77.0 has a bug.

Thanks

[mgroetan]

My issue in Devops - YAML: The zip file was uploaded, but in the storage account it was an empty file, that contained just a string with the file path! Very odd!

I've downgraded to 2.76.0 and it works as usual.

Seems 2.77.0 has a bug.

Thanks

That's exactly what I'm experiencing as well!
My problem is that I can't easily downgrade, as I'm using it from an Azure DevOps pipeline, where I get whichever version Microsoft feels like.

[OGLara]

My issue in Devops - YAML: The zip file was uploaded, but in the storage account it was an empty file, that contained just a string with the file path! Very odd!
I've downgraded to 2.76.0 and it works as usual.
Seems 2.77.0 has a bug.
Thanks

That's exactly what I'm experiencing as well! My problem is that I can't easily downgrade, as I'm using it from an Azure DevOps pipeline, where I get whichever version Microsoft feels like.

Hey @mgroetan , I can confirm I had the same problem when using Azure DevOps pipelines, where you're stuck with the agent's pre-installed version.

I found a reliable workaround. For any job where you use Azure CLI commands, you can add the following task. The key is to make it the very first step of the job, right under the steps: tag. This ensures you're using the correct version for all subsequent tasks.

Here is the snippet I used:

- task: Bash@3
  displayName: 'Install specific Azure CLI version (2.76.0)'
  inputs:
    targetType: 'inline'
    script: |
      echo "Attempting to uninstall default Azure CLI to ensure a clean slate..."
      pip uninstall -y azure-cli azure-cli-core
      echo "Installing Azure CLI version 2.76.0..."
      pip install azure-cli==2.76.0
      echo "Installation complete. Verifying version:"
      az --version

First, this script uninstalls the default version to prevent conflicts and then installs the version you specify (2.76.0 in this example).

I hope this helps you and anyone else facing this issue!