{Core} Fix 404 in long running delete operation

[fengzhou-msft]

Description

In the response of DELETE long running operation, some service (observed in some corner case of servicebus, update: confirmed in swagger review session that more services have this behavior) may return 404 while GETting operation results when the resource is successfully deleted (normally it should return 200 with no response body).

To handle the 404 case, this PR adds similar logic to the error handling in wait --deleted command:

azure-cli/src/azure-cli-core/azure/cli/core/commands/arm.py

Lines 700 to 702 in 05e3b63

	if getattr(ex, 'status_code', None) == 404:
	if wait_for_deleted:
	return None

Testing Guide

Without this PR, azdev test test_sb_alias --live will fail when deleting the secondary namespace.
With this PR, it can succeed.

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change.
[Component Name 2] az command b: Add some customer-facing feature.

---

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.

[yonzhan]

Core

[jiasli]

Is GET called on the service itself or the operation status (Azure-AsyncOperation/Location)?

[jiasli]

Even if we add this hack, Python SDK and its users will still suffers from this non-standard behavior.

[jiasli]

Do we have an open issue in https://github.com/Azure/azure-rest-api-specs to track this?

[fengzhou-msft]

I opened an issue in our repo #15906 for service team to deal with.

[fengzhou-msft]

Based on a disucssion with swagger reviewers, there are some existing services using 404 in LRO. For new swaggers, there should be validation tasks to catch it but for existing ones as long as the json is not modified with PRs, it will not be caught.

[jiasli]

I still think we should force service team to fix it, instead of patching it from our side, otherwise Python SDK and its users will still suffers from this non-standard behavior.

[fengzhou-msft]

Is GET called on the service itself or the operation status (Azure-AsyncOperation/Location)?

The error is thrown during long running operation, so I think it's called on the operation status.

        # Delete Namespace - primary
>       self.cmd('servicebus namespace delete --resource-group {rg} --name {namespacenameprimary}')

azure-cli/src/azure-cli/azure/cli/command_modules/servicebus/tests/latest/test_servicebus_alias_commands.py:163: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
azure-cli/src/azure-cli-testsdk/azure/cli/testsdk/base.py:167: in cmd
    return execute(self.cli_ctx, command, expect_failure=expect_failure).assert_with_checks(checks)
azure-cli/src/azure-cli-testsdk/azure/cli/testsdk/base.py:238: in __init__
    self._in_process_execute(cli_ctx, command, expect_failure=expect_failure)
azure-cli/src/azure-cli-testsdk/azure/cli/testsdk/base.py:301: in _in_process_execute
    raise ex.exception
env/lib/python3.8/site-packages/knack/cli.py:233: in invoke
    cmd_result = self.invocation.execute(args)
azure-cli/src/azure-cli-core/azure/cli/core/commands/__init__.py:659: in execute
    raise ex
azure-cli/src/azure-cli-core/azure/cli/core/commands/__init__.py:722: in _run_jobs_serially
    results.append(self._run_job(expanded_arg, cmd_copy))
azure-cli/src/azure-cli-core/azure/cli/core/commands/__init__.py:715: in _run_job
    six.reraise(*sys.exc_info())
env/lib/python3.8/site-packages/six.py:703: in reraise
    raise value
azure-cli/src/azure-cli-core/azure/cli/core/commands/__init__.py:704: in _run_job
    result = LongRunningOperation(cmd_copy.cli_ctx, 'Starting {}'.format(cmd_copy.name))(result)
azure-cli/src/azure-cli-core/azure/cli/core/commands/__init__.py:988: in __call__
    handle_long_running_operation_exception(client_exception)

[houk-ms]

Soft-delete and purge operation on managed-hsm also suffer from this bad behavior. It just returns 404 when the delete operation completes.

I think we should have this logic supported in CLI core to handle these cases. Maybe also add some log info to expose these cases. Of course, at the same time, we should report these bad behiviors to service team.

[houk-ms]

LGTM