saving as new revision fails when updating volumes as 'revision with suffix ***** already exists'

[philricelf]

Please provide us with the following information:

This issue is a: (mark with an x)

• [ x] bug report -> please search issues before submitting
• [ ] documentation issue or request
• [ ] regression (a behavior that used to work and stopped in a new release)

Issue description

I have Container Apps running in Single Revision mode and use Azure Files for volume mounts, which works correctly until I try to make edits to the volume settings.

Using the Azure Portal to make updates to volumes in a container app fails after clicking 'save as new revision' as the 'new' revision seems to attempt to use the same revision name as the current revision. It displays the following error:

Steps to reproduce

1. Navigate to a container app running in Single Revision mode, that has an Azure Files share configured and working as a volume mount (or create one if you do not have one!)
2. Under Application > volumes , make a change to the volume that is configured to change the file share to a different file share and click save
3. Click 'save as new revision'

Expected behavior [What you expected to happen.] A new revision to be created succesfully with a new auto generated name

Actual behavior [What actually happened.] Shows that it is 'deploying revision' but then fails with error message saying that the revision name already exists, as it has tried to use the same name as the current revision

Screenshots
If applicable, add screenshots to help explain your problem.

Image provided above

Additional context

Ex. Did this issue occur in the CLI or the Portal? Occurs in the portal Single Revision Mode Workload Profile SKU

[philricelf]

A workaround to this issue is to go into Revisions and Replicas, create a new revision from there giving it a unique name and make adjustments to the volume there. This then saves and deploys without issue

[simonjj]

We're adding this to our backlog.

[LianaAdaza]

Thank you for your report! This bug has been resolved (29331146). Please feel free to reach out if you continue to encounter difficulties.