Unable to cancel client.AcceptNextSessionForQueue(..) function

[orzel7]

pkg: github.com/Azure/azure-sdk-for-go/sdk/messaging/azservicebus

SDK version: v0.4.0

go version: go 1.18

What happened?

function client.AcceptNextSessionForQueue(ctx, queueName, options) is not cancellable by context, passed as first argument. For example, if I want to interrupt this function by signal or by timeout, I need to wait about 1 minute before function exits with error "context canceled".

[jhendrixMSFT]

I observe a hang waiting for an ack during link attachment. I'm wondering if this is due to no sessions being available (at least in my simple repro).

runtime.gopark (c:\Program Files\Go\src\runtime\proc.go:362)
runtime.selectgo (c:\Program Files\Go\src\runtime\select.go:328)
github.com/Azure/go-amqp.attachLink (c:\Users\jhendrix\go\pkg\mod\github.com\!azure\go-amqp@v0.17.4\link.go:173)
github.com/Azure/go-amqp.(*Session).NewReceiver (c:\Users\jhendrix\go\pkg\mod\github.com\!azure\go-amqp@v0.17.4\session.go:95)
github.com/Azure/azure-sdk-for-go/sdk/messaging/azservicebus.createReceiverLink (c:\git\Azure\azure-sdk-for-go\sdk\messaging\azservicebus\receiver.go:511)
github.com/Azure/azure-sdk-for-go/sdk/messaging/azservicebus.(*SessionReceiver).newLink (c:\git\Azure\azure-sdk-for-go\sdk\messaging\azservicebus\session_receiver.go:92)
github.com/Azure/azure-sdk-for-go/sdk/messaging/azservicebus.(*SessionReceiver).newLink-fm (:1)
github.com/Azure/azure-sdk-for-go/sdk/messaging/azservicebus/internal.(*AMQPLinksImpl).initWithoutLocking (c:\git\Azure\azure-sdk-for-go\sdk\messaging\azservicebus\internal\amqpLinks.go:446)
github.com/Azure/azure-sdk-for-go/sdk/messaging/azservicebus/internal.(*AMQPLinksImpl).Get (c:\git\Azure\azure-sdk-for-go\sdk\messaging\azservicebus\internal\amqpLinks.go:289)
github.com/Azure/azure-sdk-for-go/sdk/messaging/azservicebus/internal.(*AMQPLinksImpl).Retry.func2 (c:\git\Azure\azure-sdk-for-go\sdk\messaging\azservicebus\internal\amqpLinks.go:315)
github.com/Azure/azure-sdk-for-go/sdk/messaging/azservicebus/internal/utils.Retry (c:\git\Azure\azure-sdk-for-go\sdk\messaging\azservicebus\internal\utils\retrier.go:60)
github.com/Azure/azure-sdk-for-go/sdk/messaging/azservicebus/internal.(*AMQPLinksImpl).Retry (c:\git\Azure\azure-sdk-for-go\sdk\messaging\azservicebus\internal\amqpLinks.go:310)
github.com/Azure/azure-sdk-for-go/sdk/messaging/azservicebus.(*SessionReceiver).RenewSessionLock (c:\git\Azure\azure-sdk-for-go\sdk\messaging\azservicebus\session_receiver.go:220)
github.com/Azure/azure-sdk-for-go/sdk/messaging/azservicebus.newSessionReceiver (c:\git\Azure\azure-sdk-for-go\sdk\messaging\azservicebus\session_receiver.go:72)
github.com/Azure/azure-sdk-for-go/sdk/messaging/azservicebus.(*Client).AcceptNextSessionForQueue (c:\git\Azure\azure-sdk-for-go\sdk\messaging\azservicebus\client.go:265)
main.main (c:\git\jhendrixMSFT\azsbcancel\main.go:19)
runtime.main (c:\Program Files\Go\src\runtime\proc.go:250)
runtime.goexit (c:\Program Files\Go\src\runtime\asm_amd64.s:1571)

Eventually, service bus sends us a detach as the operation timed out.

@richardpark-msft is AcceptNextSessionForQueue() a blocking call until a session is available? There's no doc comment explaining the behavior.

[jhendrixMSFT]

Looking at the docs for the C# implementation, I believe this is the expected behavior. We will need to update go-amqp to take a context.Context in these cases (probably should have been there from the start).

[richardpark-msft]

Interesting, this would need to be up the entire chain:

// connection
conn = amqp.New()

// session
sess = conn.NewSession()

// receiver
session.NewReceiver()
// and probably sender as well)

In this particular case the "hanging" call is probably the worst offender. I don't think go-amqp itself is lazy, so adding cancellation into NewReceiver() initially and get the biggest bang for our buck there. I think this might be the first case in go-amqp where we cancel an operation that is actually in-flight with the service. So we probably want to discuss a bit.

[richardpark-msft]

@orzel7, glad to see you again (although sorry it's because of a bug)

I'll be taking a look at this. At a high level we'll probably have to handle this cancellation within azservicebus, rather than go-amqp (like @jhendrixMSFT and I initiallly discussed) mostly because there's some state to rollback and that's a bit easier in azservicebus at this time.

I'll update with a PR soon.

[richardpark-msft]

Hi @orzel7, a fix has been merged. Our official package releases are monthly so this isn't tagged, but you can retrieve it using the commit itself:

go get github.com/Azure/azure-sdk-for-go/sdk/messaging/azservicebus@63195b99ab9a611a0e5c9cb85a3a49390f4c6855