azure-sdk-for-net: [BUG] Azure.Messaging.ServiceBus SendMessage MessageSizeExeeded in Azure - Regression
Library name and version
Azure.Messaging.ServiceBus v7.12.0
Describe the bug
When sending batches of messages that are relatively small (sub 1k), to a standard SKU Service Bus, with the following trivialized implementation:
private ServiceBusSender _sender;
public async Task EnqueueBatchAsync<T>(List<T> messages, string correlationId)
{
var count = 0;
while (count < messages.Count)
{
using var messageBatch = await _sender.CreateMessageBatchAsync();
while (count < messages.Count)
{
var message = messages[count];
var serializedMessage = JsonConvert.SerializeObject(message);
var serviceBusMessage = new ServiceBusMessage(serializedMessage)
{
ContentType = "application/json",
MessageId = Guid.NewGuid().ToString(),
CorrelationId = correlationId
};
if (messageBatch.TryAddMessage(serviceBusMessage))
{
count++;
continue;
}
else
{
break;
}
}
await _sender.SendMessagesAsync(messageBatch);
}
}
even though the TryAddMessage attempt fails as expected before the batch is full, the batch fails to send with the following error message:
{“The message (id:15939002, size:265268 bytes) is larger than is currently allowed (262144 bytes). (MessageSizeExceeded). For troubleshooting information, see https://aka.ms/azsdk/net/servicebus/exceptions/troubleshoot.”}
This appears to be a regression of https://github.com/Azure/azure-sdk-for-net/issues/19053 and downgrading from 7.12.0 to 7.11.1 fixes the issue.
Expected behavior
All metadata associated with the message should be included in the size calculation of TryAddMessage, ensuring that the batch can be sent.
Actual behavior
The total size is inaccurate, resulting in the batch not being sent.
Reproduction Steps
See above.
Environment
.NET 7 on Windows 10.
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 38 (18 by maintainers)
Good point - the library does provide a means to check if the properties are set without accessing them via the Sections property of AmqpMessage. This does seem like a new issue as of 7.11.0 because previously we didn’t use the AmqpMessage properties, but rather the higher level ServiceBusMessage properties which was not backed by the AmqpMessage properties. So we should at least fix that. But still I’m not seeing how that would cause the discrepancy as we checked these properties before building the batch. I’ll take another look in the morning.
I’m afraid I can’t prove anything about 7.10.0 right now because I can’t reproduce anything at the moment, not sure what has changed 😕
I’ve run out of time for today, I will take another look tomorrow.
@DavidAtImpactCubed I updated your post that was sharing the second example as it was not sanitized.
I’m struggling to put together a consistently reproducible example, but I think I might have something that might help:
Running the attached code, I put two breakpoints, one in Program.cs, where I check the messageBatch SizeInBytes:
And one in Azure.Messaging.ServiceBus.Amqp.AmqpSender on line 274, where the AmqpDataMessage size is checked:
As you can see, the AmqpDataMessage is a byte bigger for some reason.
The max message size is the same in both cases: 262144
This seems to be consistently a 1 byte difference, which isn’t the same as what @Stabzs was seeing, where the difference was much bigger, but maybe it gives a hint as to where the difference is creeping in? Not sure if this helps, but figured I might as well share…
Thank you for your feedback. Tagging and routing to the team member best able to assist.