-
Notifications
You must be signed in to change notification settings - Fork 3.3k
[CosmosDB] Fix #32608: az cosmosdb restore: Fix "Database Account does not exist" error during polling #32752
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: dev
Are you sure you want to change the base?
Conversation
❌AzureCLI-FullTest
|
️✔️AzureCLI-BreakingChangeTest
|
|
Thank you for your contribution! We will review the pull request and get back to you soon. |
|
The git hooks are available for azure-cli and azure-cli-extensions repos. They could help you run required checks before creating the PR. Please sync the latest code with latest dev branch (for azure-cli) or main branch (for azure-cli-extensions). pip install azdev --upgrade
azdev setup -c <your azure-cli repo path> -r <your azure-cli-extensions repo path>
|
|
Thank you for your contribution @jcassanji-southworks! We will review the pull request and get back to you soon. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR attempts to fix a known issue where az cosmosdb restore fails with a "Database Account does not exist" error during polling. The Azure backend service occasionally appends the location name to the account name during restore operations, causing a 403 Forbidden error. The fix implements error handling in _create_database_account to catch this specific error and fall back to using client.get() to verify account creation.
Changes:
- Added exception handling in
custom.pyto catch and suppress specific 403 "does not exist" errors during restore operations - Added comprehensive unit tests in
test_cosmosdb_backuprestore_scenario.pyto verify the error handling logic
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 8 comments.
| File | Description |
|---|---|
| src/azure-cli/azure/cli/command_modules/cosmosdb/custom.py | Added try-except block around async_docdb_create.result() to handle the service bug where location is appended to account name, with fallback to client.get() |
| src/azure-cli/azure/cli/command_modules/cosmosdb/tests/latest/test_cosmosdb_backuprestore_scenario.py | Added unit test class CosmosDBRestoreUnitTests with three test cases covering the forbidden error handling, other errors, and normal create operations |
Comments suppressed due to low confidence (4)
src/azure-cli/azure/cli/command_modules/cosmosdb/custom.py:422
- The comment label "# Workaround" on this line is misleading because it applies to all account creation operations, not just the workaround for the specific restore bug. This line should always execute to retrieve the final account state, but the comment suggests it's part of the temporary workaround. Consider clarifying the comment or removing it since this is standard behavior.
src/azure-cli/azure/cli/command_modules/cosmosdb/custom.py:422 - Missing error handling: When the specific 403 error is caught and
client.get()is called as a fallback, there's no verification that the restore operation actually succeeded. The code should check theprovisioning_stateor other indicators from the account returned byclient.get()to ensure the operation completed successfully. Without this check, a failed restore could be silently treated as successful.
raise ex
docdb_account = client.get(resource_group_name, account_name) # Workaround
return docdb_account
src/azure-cli/azure/cli/command_modules/cosmosdb/custom.py:422
- Missing error handling: If the workaround triggers but the account genuinely doesn't exist yet (e.g., the operation is still in progress),
client.get()could raise aResourceNotFoundError. This exception should be caught and handled appropriately, potentially with retry logic or a clearer error message explaining that the restore operation status is unclear.
raise ex
docdb_account = client.get(resource_group_name, account_name) # Workaround
return docdb_account
src/azure-cli/azure/cli/command_modules/cosmosdb/custom.py:422
- Critical bug: Line 422
client.get()is now always executed, even when the operation succeeds normally. This changes the behavior for all database account creation operations, not just restore operations with the specific error.
The logic should be:
- If no exception occurs, use the result from
async_docdb_create.result()and return it - If the specific 403 error occurs during restore, fall back to
client.get()
Current implementation causes an unnecessary additional API call for every successful account creation, and more importantly, the result from the successful poller.result() is discarded. The variable docdb_account is assigned on line 413 but then immediately overwritten on line 422 regardless of whether an exception occurred.
Fix: Move line 422 inside the exception handler (after line 419) so it only executes when the specific error is caught.
try:
docdb_account = async_docdb_create.result()
except HttpResponseError as ex:
if is_restore_request and ex.status_code == 403 and "does not exist" in str(ex):
pass
else:
raise ex
docdb_account = client.get(resource_group_name, account_name) # Workaround
return docdb_account
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
...-cli/azure/cli/command_modules/cosmosdb/tests/latest/test_cosmosdb_backuprestore_scenario.py
Outdated
Show resolved
Hide resolved
...-cli/azure/cli/command_modules/cosmosdb/tests/latest/test_cosmosdb_backuprestore_scenario.py
Outdated
Show resolved
Hide resolved
...-cli/azure/cli/command_modules/cosmosdb/tests/latest/test_cosmosdb_backuprestore_scenario.py
Outdated
Show resolved
Hide resolved
...-cli/azure/cli/command_modules/cosmosdb/tests/latest/test_cosmosdb_backuprestore_scenario.py
Outdated
Show resolved
Hide resolved
...-cli/azure/cli/command_modules/cosmosdb/tests/latest/test_cosmosdb_backuprestore_scenario.py
Show resolved
Hide resolved
...-cli/azure/cli/command_modules/cosmosdb/tests/latest/test_cosmosdb_backuprestore_scenario.py
Outdated
Show resolved
Hide resolved
…test_cosmosdb_backuprestore_scenario.py Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
…test_cosmosdb_backuprestore_scenario.py Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
…o-name-causing-it-to-fail-fix' of https://github.com/jcassanji-southworks/azure-cli into 32608-az-cosmosdb-restore-wrongfully-appends-location-to-name-causing-it-to-fail-fix
Related command
az cosmosdb restoreDescription
This PR fixes a known issue (GitHub Issue #28434) where
az cosmosdb restorecommand fails with a(Forbidden) Database Account <account-name>-<location> does not existerror.The Azure backend service occasionally appends the location name to the account name during the polling operation of a restore action. This causes the CLI to poll a non-existent account name (e.g.,
myaccount-westeuropeinstead ofmyaccount), resulting in a 403 Forbidden error.Changes:
custom.pyto catch and suppress the specificHttpResponseError(403 Forbidden with "does not exist") during the polling ofclient.begin_create_or_update.client.getto verify if the account was successfully created/restored when this error is encountered.test_cosmosdb_backuprestore_scenario.pyto ensure the fix handles the specific error condition correctly without masking other legitimate errors.Testing Guide
Run the newly added unit tests to verify the fix:
History Notes
[CosmosDB]
az cosmosdb restore: Fix bug where restore operation fails with "Database Account does not exist" error due to incorrect location appending.This checklist is used to make sure that common guidelines for a pull request are followed.
The PR title and description has followed the guideline in Submitting Pull Requests.
I adhere to the Command Guidelines.
I adhere to the Error Handling Guidelines.