ServiceBusSender Identifier not set.

[woodylaurence]

Library name and version

Azure.Messaging.ServiceBus v7.18.0+

Describe the bug

When creating a ServiceBusSender using ServiceBusClient.CreateSender() the returned Sender does not have its Identifier correctly set based off the queue/topic name.
This used to work < 7.18.0.

Expected behavior

ServiceBusClient.CreateSender() should return ServiceBusSender with Identifier set as -.

Actual behavior

Identifier is set as "-".

Reproduction Steps

using Azure.Identity;
using Azure.Messaging.ServiceBus;

namespace ConsoleApp1;

class Program
{
	static void Main(string[] args)
	{
		var serviceBusClient = new ServiceBusClient("service-bus-name.servicebus.windows.net", new DefaultAzureCredential());
		var serviceBusSender = serviceBusClient.CreateSender("queue-name");
	}
}

Environment

No response

[github-actions]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[jsquire]

Hi @woodylaurence. Thanks for reaching out and we regret that you're experiencing difficulties. Confirming that this is a bug that was introduced this commit, which changed the flow where the identifier is being created. The code should have been updated to use the entityPath parameter instead of EntityPath property, which is not yet initialized. Looks like ServiceBusClient is also impacted. We'll get this fixed up and hope to have it available for our next release in early January.

In the meantime, mitigation would be to use the options to explicitly set an identifier. The following will restore the intended behavior:

await using var client = new ServiceBusClient"<< Fully Qualified Namespace >>", new DefaultAzureCredential());

var entityPath = "myQueue";
var options = new ServiceBusSenderOptions { Identifier = $"{entityPath}-{Guid.NewGuid()}" };
var sender = client.CreateSender(entityPath, options);

[woodylaurence]

Thanks @jsquire !

Solution will work for us for now and will keep an eye out for the release so that we can revert the temporary fix.

[jsquire]

fixed by #47346