[azservicebus] Making a unit test more reliable by blocking instead of relying on "hopeful" timing. (Azure#18215)

Making a unit test more reliable by blocking instead of relying on "hopeful" timing.

Fixes Azure#18174

Author: richardpark-msft

sdk/messaging/azservicebus/receiver_unit_test.go

@@ -311,19 +311,32 @@ func TestReceiver_CanCancelLinkCreation(t *testing.T) {
 		},
 	}
 
+	done := make(chan struct{})
+
 	session := &internal.FakeAMQPSession{
 		NewReceiverFn: func(opts ...amqp.LinkOption) (internal.AMQPReceiverCloser, error) {
 			// simulate the client cancelling while we're stuck attempting to get the
 			// session receiver link.
 			cancel()
+
+			// "block" here. Basically what we're trying to simulate is that there's an
+			// active NewReceiver() and then we cancel.
+			select {
+			case <-done:
+			case <-time.After(5 * time.Second):
+				require.Fail(t, "Timed out waiting for the cancellation token to be respected.")
+			}
 			return fakeReceiver, nil
 		},
 	}
 
 	receiver, err := createReceiverLink(ctx, session, []amqp.LinkOption{})
 	require.Nil(t, receiver)
+	require.NotNil(t, err)
 	require.ErrorIs(t, err, context.Canceled, fmt.Sprintf("%s is context.Cancelled", err.Error()))
 
+	close(done)
+
 	// also, the receiver we returned should be closed as part of the gourtine
 	// unwinding.
 	<-receiverWasClosedCh