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

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

Use azure-cli version 2.77.0.

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"

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

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

David Watrous (@dpwatrous)

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc David Watrous (@dpwatrous), wiboris, Rena (@cRui861), Sanjana Kapur (@skapur12), Haopeng Wang (@wanghoppe).

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

David Watrous (@dpwatrous)

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc David Watrous (@dpwatrous), wiboris, Rena (@cRui861), Sanjana Kapur (@skapur12), Haopeng Wang (@wanghoppe).

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

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.

Morten Grøtan (@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.

Hey Morten Grøtan (@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!

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!

Thank you very much, that definitely did the trick!
Somewhat worryingly (for me), when seeing that workaround, I realized I had done the very same thing a few years back, fixing an other breaking change in Azure CLI....

[Batch] Fix Azure#32086, Azure#32090: `az batch application package c…

Zhiyi Huang (@calvinhzy)

Zhiyi Huang (@calvinhzy)
David Watrous (@dpwatrous), wiboris, Rena (@cRui861), Sanjana Kapur (@skapur12), Haopeng Wang (@wanghoppe)

Issue is still persisting in our azure devops pipeline with azure-cli 2.77.0 version

Starting: Upload Pump application package to Batch Account (windows_build_container)
Task : Azure CLI
Description : Run Azure CLI commands against an Azure subscription in a Shell script when running on Linux agent or Batch script when running on Windows agent.
Version : 1.247.1
Author : Microsoft Corporation
Help : https://docs.microsoft.com/azure/devops/pipelines/tasks/deploy/azure-cli
C:\Windows\system32\cmd.exe /D /S /C ""C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin\az.cmd" --version"
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

.....................................................

C:__w\1\s>az batch application package create --application-name pump --name batchpricelistdatappeeus --resource-group rg-pricelistdata-ppe-eus2-01 --version 1 --package-file=C:__w\1\s/Pump.zip
ERROR: The specified blob already exists.
RequestId:7ad0f268-801e-0080-569f-31b857000000
Time:2025-09-30T00:14:32.4164620Z
ErrorCode:BlobAlreadyExists

Oscar Garcia de Lara Parreño (@OGLara)

Oscar Garcia de Lara Parreño (@OGLara) are you still encountering this issue? seems like they closed it but I'm still experiencing it and wondering if you're also experiencing that. I am not able to replicate your solution to choose a different version in AzureDevOps pipelines so this is blocking our release

The new version 2.78.0 will be released on 10/14 and will have the fix #32106

Navigation Menu

Repository navigation

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

Related command

Errors

Issue script & Debug output

Expected behavior

Environment Summary

Additional context

Solution 1:

Solution 2:

Solution 3:

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Related command

Errors

Issue script & Debug output

Expected behavior

Environment Summary

Additional context

Activity

yonzhan commented on Sep 9, 2025

microsoft-github-policy-service commented on Sep 9, 2025

github-actions commented on Sep 9, 2025

Solution 1:

Solution 2:

Solution 3:

microsoft-github-policy-service commented on Sep 9, 2025

Luther-Varys commented on Sep 10, 2025

mgroetan commented on Sep 12, 2025

OGLara commented on Sep 12, 2025

mgroetan commented on Sep 12, 2025

Menna13 commented on Oct 1, 2025

Menna13 commented on Oct 3, 2025

calvinhzy commented on Oct 13, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions