[Storage] Confusing behavior accessing nonexistent Azure Queue Storage

[shwars]

• Package Name: azure-storage-queue
• Package Version: 12.1.3
• Operating System: windows / linux
• Python Version: 3.7.4

Describe the bug
When trying to access non-existent account of Azure queue storage, QueueClient is created w/out errors, and calling receive_messages() results in a long timeout (followed by an error).

To Reproduce:

Consider the following code:

from azure.storage.queue import QueueClient
conn = "<correctly formed connection string with invalid account name>"

print("Creating client")
queue_client = QueueClient.from_connection_string(conn, "thequeue")

print("Getting queue messages")
for x in queue_client.receive_messages():
    print(x)

This code prints both messages immediately, followed by a long (80 seconds) delay. Traceback of an error that follows is available here

The long timeout behavior is confusing, especially when you are debugging a program that has an endless loop over queue messages, and you are wondering, why it is not executing.

Expected behavior
One of the following options:

1. Error about non-existing account name upon creation of QueueClient (I understand this might not be possible, because additional REST call would be required)
2. Shorter timeout
3. Some indication in the error message about possibility of non-existing account.

[ghost]

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

[tasherif-msft]

Hi @shwars I was able to reproduce the issue, I'm gonna look into finding a solution for getting a shorter timeout and will get back to you :)

[xiafu-msft]

hi @shwars

This should be resolved if you set retry_connect=0 when initiating QueueClient, this will help throw immediately on connection failure. currently the connection_timeout=20 (seconds) you can set to a smaller value if you want.

Let me know if you have any questions!

[shwars]

Hi @xiafu-msft, thank you for the clarification. I was thinking about the possibility to manually setting timeout to smaller value. However, considering first-time user, it would be convenient to have timeout set to some reasonable value by default. 20 seconds is probably a reasonable value (although rather on a long side), but it is not clear why the actual waiting time in my case is 80 seconds, and not 20.

[xiafu-msft]

Hi @shwars

SDK defaults retry_connect=3, which means SDK will automatically retry to connect for you internally.
Setting retry_connect=0 will stop from retry when there's connection error.

[shwars]

Thanks for the explanation, @xiafu-msft. I understand where the problem is coming from. My concern is that for a non-experienced user who does not understand the internals this 80-seconds delay will look extremely strange, and make things more difficult to debug. Do you think that we should add the notice to docs saying that invalid queue name will result in a long timeout?

[xiafu-msft]

Hi @shwars

That's a good suggestion, we absolutely should make the doc better and friendly to non-experienced user!

[xiafu-msft]

Hi @shwars

Just an update.
It seems @tadam-msft has some thoughts to make optional configurations more obvious to new customers.
Then probably we don't need to update the quick start doc, since this doc is for basic operations probably we want to keep it simple.
I think SDK API doc could be a better place to have the info, let me know how you feel about that!

[shwars]

@xiafu-msft This problem was discovered as part of an end-to-end scenario, where I tried to evaluate how seamless is the technology for beginners. I believe that long 30 sec timeout instead of an error message is kind of misleading, and thus I think at least a short paragraph of text explaining this behaviour is nice to have in a quickstart document.

[xiafu-msft]

close this issue for now since the link has been added, feel free to comment on it or open a new issue if you have any other questions!