Command to wait for SQL Server state fails

[valterc]

Describe the bug

Using Azure CLI to wait for a SQL Server state fails with the following stack trace:

Command Name
az sql server wait

Errors:

'NoneType' object has no attribute 'casefold'
Traceback (most recent call last):
Temp\pip-install-3pnsb50r\knack\knack\cli.py, ln 206, in invoke
azure\cli\core\commands\__init__.py, ln 608, in execute
azure\cli\core\commands\__init__.py, ln 666, in _run_jobs_serially
azure\cli\core\commands\__init__.py, ln 659, in _run_job
Local\Temp\pip-install-3pnsb50r\six\six.py, ln 703, in reraise
azure\cli\core\commands\__init__.py, ln 636, in _run_job
azure\cli\core\commands\__init__.py, ln 306, in __call__
azure\cli\core\commands\arm.py, ln 684, in handler
AttributeError: 'NoneType' object has no attribute 'casefold'

To Reproduce:

Steps to reproduce the behavior:

• az login
• az account set --subscription {}
• az sql server wait --name {} --resource-group {} --created

Expected Behavior

Command waits for a few seconds or returns immediately with no errors.

Environment Summary

Windows-10-10.0.18362-SP0
Python 3.6.6

azure-cli 2.1.0

Additional Context

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @azureSQLGitHub

[yonzhan]

az sql

[a-vishar]

Any update on this?

[jaredmoo]

Error:

'NoneType' object has no attribute 'casefold'
Traceback (most recent call last):
Temp\pip-install-3pnsb50r\knack\knack\cli.py, ln 206, in invoke
azure\cli\core\commands\__init__.py, ln 608, in execute
azure\cli\core\commands\__init__.py, ln 666, in _run_jobs_serially
azure\cli\core\commands\__init__.py, ln 659, in _run_job
Local\Temp\pip-install-3pnsb50r\six\six.py, ln 703, in reraise
azure\cli\core\commands\__init__.py, ln 636, in _run_job
azure\cli\core\commands\__init__.py, ln 306, in __call__
azure\cli\core\commands\arm.py, ln 684, in handler
AttributeError: 'NoneType' object has no attribute 'casefold'  

Code:

               provisioning_state = get_provisioning_state(instance)
                # until we have any needs to wait for 'Failed', let us bail out on this
                if provisioning_state.casefold() == 'failed':
                    progress_indicator.stop()
                    raise CLIError('The operation failed')

[jaredmoo]

Caused by #12154

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @armleads-azure

[jaredmoo]

SQL server does not use provisioning state. Please fix this bug and implement automated test for az sql server wait (which should have been done when core team implemented this command, and would have prevented this regression).

[a-vishar]

Any update on this?

[jiasli]

Fixed the regression with #12532

From the --debug log of az sql server wait, the sql server doesn't use "provisioningState": "Succeeded", but "state": "Ready".

{
    "kind": "v12.0",
    "properties": {
        "administratorLogin": "{}",
        "version": "12.0",
        "state": "Ready",
        "fullyQualifiedDomainName": "{}.database.windows.net",
        "privateEndpointConnections": [],
        "publicNetworkAccess": "Enabled"
    },
    "location": "eastus",
    "id": "/subscriptions/0b1f6471-1bf0-4dda-aec3-cb9272f09590/resourceGroups/{}/providers/Microsoft.Sql/servers/{}",
    "name": "{}",
    "type": "Microsoft.Sql/servers"
}

Since wait is a generic ARM command, I am not sure whether we need to make an exception for SQL or add --ready since this will confuse customers using other commands like vm wait --created.

For now you may use custom query state=='Ready'

az sql server wait --resource-group {} --name {} --custom "state=='Ready'"

@jaredmoo @Juliehzl Any thoughts?

[navba-MSFT]

@valterc Apologies for the late reply. This github thread has been open for quite sometime. Could you please let us know if you are still looking for some assistance on this issue ?

[valterc]

I haven't used that command in a while, not sure if the problem still remains. If it was fixed or if there's no more reports I guess it could be closed. Thank you.

[navba-MSFT]

@valterc As per the above comment this is fixed, Refer #12532. So with your permission we will now proceed with the closure of this thread. If you need any further assistance, feel free to reopen this thread. We could be happy to assist.