[BUG] ServiceBusReceiver.PeekMessageAsync does not respect cancellation token on connect failure

[andradf]

Library name and version

Azure.Messaging.ServiceBus 7.20.1

Describe the bug

For cases when the service bus endpoint is not reachable, the cancellation token passed to PeekMessageAsync is not respected.

Expected behavior

The call to PeekMessageAsync should timeout on a failed connection attempt in accordance to the cancellation token passed in the call.

Actual behavior

the connection times out at a fixed 65 seconds.

Reproduction Steps

Execute the following in an environment where the service bus instance cannot be reached.

var service_bus_client = new Azure.Messaging.ServiceBus.ServiceBusClient("<CSTR>");
var receiver = service_bus_client.CreateReceiver("ej-file-commands");
CancellationTokenSource cts = new CancellationTokenSource(TimeSpan.FromSeconds(5));
cts.Token.Register(() => Console.WriteLine("Cancellation requested"));
await receiver.PeekMessageAsync(cancellationToken: cts.Token);

Environment

Windows and .net runtime 9.0.8

[jsquire]

Hi @andradf. Thanks for reaching out and we regret that you're experiencing difficulties. The behavior that you're seeing is by design and an artifact of cancellation being "best effort" and not a guarantee in the underlying AMQP transport.

In a connection scenario, the client does its best to honor cancellation when it is safe to do so. However, there is a point where the operation has been passed to the network and is out of control of the client. When cancellation is signaled at this point, the AMQP transport may decide that the flow has progressed too far to safely cancel or may not have direct control of the network's behavior. The client prioritizes ensuring that it does end up in an inconsistent state that would cause resource issues in the application. Likewise, the underlying transport applies similar logic to ensure that resources are not left in an inconsistent state that would impact the service itself or the ability for other clients/connections to be used.

From the behavior that you're describing, the connection flow is in-flight and control has transferred to the AMQP transport (and presumably, the underlying network) which is using the TryTimeout configured on your retry policy. The client has no insight nor influence in this state. If you would like deeper context or to discuss further, your best path forward would be to open an issue where the Microsoft.Azure.Amqp transport library is maintained.

[github-actions]

Hi @andradf. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text "/unresolve" to remove the "issue-addressed" label and continue the conversation.

[github-actions]

Hi @andradf, since you haven’t asked that we /unresolve the issue, we’ll close this out. If you believe further discussion is needed, please add a comment /unresolve to reopen the issue.