Request for additional sending link metadata for service limitations

[jsquire]

Problem statement

To provide the best possible developer experience, the Service Bus client library attempts to eagerly validate caller-provided data before invoking a service operation to allow for a more responsive API. To avoid drift between the client and service enforcement, the client limits validations to items that either have meaning only to the client or that are based on information that the Service Bus service provides.

When publishing messages, there are a few cases which are impactful to developers and for which the client lacks appropriate context to provide a good experience:

• When large message support is enabled, the standard message size limit is still applied to batched messages. At the time of writing, the Service Bus service rejects any batch larger than 1024MB regardless of the configured maximum message size. Because the service communicates only the maximum message size allowed by the AMQP link, the client library is unable to set the actual limit on the batch, allowing developers to create batches that can never successfully be sent.

• There is a maximum number of items that the service will accept in a single operation, regardless of any size considerations. At the time of writing, the Service Bus service will reject any request containing more than 4,500 messages. Because the service doesn't communicate the object limit, the client library is unable to validate that constraint or provide a guided development experience for ensuring safe limits.

Potential workarounds

Because certain service limits are not discoverable, the only viable workaround would be for the client library to hardcode assumptions for the maximum standard message size and maximum message limit and enforce them. Some of the shortcomings of this approach are:

• The client logic may become out-of-sync with the limits enforced by the Service Bus service. This would lead to a developer experience where the service may reject operations that the client library believes are valid or the client library may be artificially limiting throughput for callers.

• The client logic would have to potentially account for differences in the limits by tier of resource, which exacerbates the first point by adding more potential for drift and additional points of failure.

• Each version of the client library would have a baked-in limit; this would potentially cause drift between versions of the client library and/or the client libraries in different languages, further exacerbating the first point and making developer troubleshooting more difficult.

Desired outcome

• When a sending link is negotiated between the Service Bus client library and the service, the link settings contain a member in the Settings collection that defines the maximum message size (in bytes) that the service will accept for any batch sent as part of a single publishing operation.

• When a sending link is negotiated between the Service Bus client library and the service, the link settings contain a member in the Settings collection that defines the maximum message count that the service will accept for any batch sent as part of a single publishing operation.

• The maximum message limit continues to be set and represents the largest size of a single message that the specific Service Bus entity associated with a sending link will accept.

References and related

• [Azure Service Bus] Batch.TryAdd should respect service limits of 4500 items max (#19125)
• [BUG] Batch.TryAdd returns true on premium with large message support but sending the batch throws an InvalidOperationException (#44261)

[jsquire]

//cc: @EldertGrootenboer

[EldertGrootenboer]

Thank you for the feedback, we already have several items around this in our backlog, and hope to have updates around these in the coming months. Once we have updates, we will share these here.