Increase the maximum length of the name of a topic subscription
Currently, the name of a subscriber to an Azure Service Bus topic is limited to 50 characters. We would like to use very descriptive names for our subscribers, and these names might exceed 50 characters. Please increase the maximum length of this value.
Simon Pinn commented
Agree - went to demo NServiceBus with ASB as the transport and BOOM :(
This seems like a basic requirement.
Josh Rogers commented
Here we are 2 years later and we still have this highly restrictive naming constraint. 50 Characters is simply not enough if you want to use descriptive names. UUID's are not an option, I shouldn't need to look up an excel sheet or otherwise to find out what a queue does when looking at it through the portal.
Agreed. In a microservice based system especially where you might have tens of more subscriptions to a given topic, this is untenable.
Cy Scott commented
If there are some difficult/impossible limitations to overcome to increase the limit of the name from 50 characters, then I would like the possibility of attaching a description to the subscription so that I can use that to organize my subscriptions instead of using the name.
Denny Crane commented
I agree. This has to be one of the most frustrating limitations to deal with and is actually motivating us to consider moving off of ASB for RabbitMQ, but I'd rather not have to deal with this migration.
As mentioned below, there are products out here that help manage the queues as a proper service bus, and they use the fully qualified class names to keep track of this stuff and to deal with serialization. Those FQNs can get long.
Alexander Y commented
The arguments used by SB team in the previous (closed issue with no resolution) issue (https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/4175354-increase-the-maximum-length-of-the-name-of-a-topic) are really weak - UUID is not a good name for a subscription, I'm sorry.
In anything relatively complex with many topics / subscriptions one would want to have a clearly identifiable subscriptions, not cryptic UUIDs. In our system we have automatic topic / subscription management that bases topic / subscription name on the class type name that processes messages. To be able to be unique we do need to follow a predictable, deterministic naming convention and UUID is not that by any stretch of imagination.
I find it illogical to cap a subscription name at some arbitrary length with no real arguments for that except - "we just feel like keeping it short". And closing an issue with 75 votes is really not a correct way to manage the feedback.