Azure-cli: cannot delete wcf relay that has empty string as a name

[tbock]

This is autogenerated. Please review and update as needed.

Describe the bug

When trying to delete a wcf relay that has no name this error is thrown. Using the list command the wcf relay shows up with "name": "".

Command Name
az relay wcfrelay delete

Errors:

Parameter 'relay_name' must have length greater than 1.
Traceback (most recent call last):
Temp\pip-install-68v0_w99\knack\knack\cli.py, ln 206, in invoke
azure\cli\core\commands\__init__.py, ln 523, in execute
azure\cli\core\commands\__init__.py, ln 581, in _run_jobs_serially
azure\cli\core\commands\__init__.py, ln 574, in _run_job
Local\Temp\pip-install-68v0_w99\six\six.py, ln 693, in reraise
azure\cli\core\commands\__init__.py, ln 551, in _run_job
azure\cli\core\commands\__init__.py, ln 289, in __call__
azure-cli-core\azure\cli\core\__init__.py, ln 453, in default_command_handler
azure\mgmt\relay\operations\wcf_relays_operations.py, ln 204, in delete
Temp\pip-install-68v0_w99\msrest\msrest\serialization.py, ln 592, in url
Temp\pip-install-68v0_w99\msrest\msrest\serialization.py, ln 672, in validate
msrest.exceptions.ValidationError: Parameter 'relay_name' must have length greater than 1.

To Reproduce:

Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

• _Put any pre-requisite steps here..._
• az relay wcfrelay delete --ids {}

Expected Behavior

Environment Summary

Windows-10-10.0.17134-SP0
Python 3.6.6
Shell: powershell.exe

azure-cli 2.0.63

Additional Context

[tbock]

Does not seem to be bug in cli but more an operation that is not supported in the API (https://docs.microsoft.com/en-us/rest/api/relay/wcfrelays/delete). How does one get rid of a nameless wcf relay.

[tjprescott]

It is a bug because when you supply an ID the CLI should extract the name from the ID.

[tbock]

To be clear this is what the id looks like:
"/subscriptions/{subscription_id}/resourceGroups/{resource_group}/providers/Microsoft.Relay/namespaces/{namespace}/wcfRelays/"

[tjprescott]

In that case you are talking about a usage error... BUT... the CLI should really be able to catch and wrap a ValidationError so no stack trace is thrown.

[tbock]

Fair but I'm not following the usage error. This is the id returned by the CLI/Rest API. Is there no way to delete,update etc a relay with an ID like that?

[tjprescott]

No. What are you trying to do? Delete all relays in the namespace?

[tjprescott]

Looking back at the comments, I see that you say the list command shows name as empty string. How did you create this relay in the first place? Was name not required?

[tjprescott]

Can you provide the command you used to create the relay? When I tried to repro, I was not able to create a relay without specifying a name.

[tbock]

Hah... yeah that's the key to my problem. Someone has misconfigured a .net based client and inadvertently created this relay. This has broken the namespace as no other relays can be created (an AddressAlreadyInUseException is thrown when the client attempts to create a named relay). Azure support indicates having a listener on the root is not supported, yet the service allows the relay to be created and does not attempt to reject it outright. As a temporary stop-gap, I was attempting to remove the relay in an effort to allow other relays to be established. Given my experience with this cli the rest api and the fact that support says a root listener is "not supported" I am very perplexed why this situation is allowed to happen at all.

Apologies if it seems like I am slow rolling the information ... that was not my intention.

[tjprescott]

No worries. In this case, the Validation that is blocking your command is not actually in the CLI, but in the SDK. Your best bet to try and delete this anomalous relay would be to try the portal or using the rest API directly, which would bypass that validation. If that doesn't work, I'd recommend you open a support ticket from the portal to see if they can get the service team to remove the relay on their end.

[tjprescott]

I'm flagging this with service attention to call out that the service allowed creation of a bad relay, but the CLI command is actually working as intended and as specified in Swagger.

[tbock]

Tried via the rest API. That was a no go as it requires a name as well. Asked support to remove the relay, they more or less said no as the client will just recreate it unless it is reconfigured. Which led me here as a stop gap, while we work on other solutions, to keep removing the relay myself repeatedly in the hopes of other relays retrying and connecting before the unnamed relay to is recreated. I now agree it seems like the CLI is working correctly since rest API doesn't support this either. But the fact remains if it can't be removed (and is "not support")... why is it allowed to be created and not blocked in the first place?

[tjprescott]

@tbock that would be a bug in the service end, which may still exist or may have been fixed (which is why I'm leaving this issue open with the ServiceAttention label). It doesn't help your situation. If is it permissible in your scenario, can you delete the relay namespace and recreate it? Deleting the namespace should wipe out any child resources.

[tbock]

Thanks for your attention. I will look into that option.

sidenote... cli is great so thanks for that.

[tjprescott]

Thanks @tbock. I hope you get it straightened out, and I did open a PR so that you at least don't get an ugly stack trace when a validation error is thrown by the SDK, so you are helping make the CLI better :)

[dlstucki]

A bit of history since Relay Cloud Service has been around for over 10 years... The original-style relays only existed as long as a listener was connected. There were no separate Create/Delete operations. A listener connecting created the relay and listener disconnecting resulted in the relay being deleted. I refer to these as "Dynamic" relays and they are still supported to this day. Listeners running in this original mode _are_ allowed to listen at the root of the namespace (EndpointAddress/Name = ""). It's an intentional feature not some oversight or bug. We cannot remove it because there are people using this feature in their applications.

Later, when SharedAccessSignature support was added to ServiceBus a place was needed to store the list of rules for any given relay endpoint. For example, in order to have a listen-only rule for "/endpoint1" a manageable "thing" needed to exist even when no listener was connected. At that time management operations where introduced creating "Persistent" relays (IsDynamic=false). Persistent Relays (and HybridConnections) allow Create, Update, and Delete management operations. Listing the relays gives you both persistent and dynamic relays. However, you can only call delete/update on persistent relays.

In cases where there's a rogue listener (v1/dynamic) listening at the root of the namespace, if you cannot find the process the listener is running in and shut it down, the only way to "kill" that listener is to roll the SAS keys for the Azure Relay Namespace. Then, within 20 or 60 minutes if the listener is using SDK defaults, or max 24 hours, the listener at the root of the namespace will be disconnected because it no longer has valid credentials.

[jfggdl]

@tbock, would you please confirm if you have tried or able to try what @dlstucki suggested as a way to "kill" a dynamic listener at the root of the namespace?

[tbock]

Not using the CLI but yes that is the route we took and are working to reconfigure how we use service bus to avoid this pitfall. Thank you for the background @dlstucki

[jfggdl]

@tbock, great. I am going to close this issue, but feel free to reopen it if after your reconfiguration you still have questions or problems.