[Feature Req] ServiceBusMessageSender should refresh maximum message size when service settings change

[SeanFeldman]

Library name and version

Azure.Messaging.ServiceBus

Describe the bug

When using a ServiceBusMessageSender instance while there's a change to the entity's maximum message size, the Batch API doesn't allow message adding despite the message being within the allowed size. The client holds on to the old maximum message size it has retrieved from the entity, which is confusing.

Expected behavior

Messages that previously couldn't be sent to be sent w/o the need to restart the process.

Actual behavior

The process has to be restarted to get the updated max message size.

Reproduction Steps

On a premium namespace, a queue of size S1. Start a process that sends a message larger than S1.
Increase the entity maz size to S2 (S2 > S1). Adding messages to a batch messageBatch.TryAddMessage(message) be unsuccessful.

Environment

No response

[github-actions]

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

[jsquire]

Hi @SeanFeldman. Thanks for letting us know. The current implementation is based on the now outdated service limitation that the maximum message size was based on the SKU and was not configurable. As the service feature set changed, this was overlooked in the client.

There's a bit of a tricky balance here. I don't think that we want to force every call to CreateMessageBatchAsync to be checking the link for the unlikely case that the message size could change. I do think that it would be reasonable to reevaluate the maximum message size on send, where we're already network bound. This would mean that the client won't refresh in real-time but would adjust before each send operation. I think that's a reasonable trade-off to avoid impacting performance each time a batch is created, but I'd appreciate your thoughts.

Regardless of how the client adjusts, we'd also need a service-side feature for this to work. Currently, the entity does not detatch existing AMQP connections/links when settings change. Since the maximum message size is communicated to the client via metadata on the link, for the client to be aware of changes, it needs to open a new link on which the service has set that updated metadata. I've opened #705 for the Service Bus team.

In the meantime, the proposed client changes are safe to make, so we'll look at getting them in.

[SeanFeldman]

@jsquire, that's a good approach 👍

[jsquire]

Client portions addressed in #44328. It should help a bit, but won't be fully effective until the service forces client disconnection when the size is updated.

[jsquire]

Changes merged and will be available in our next release.