ScheduleMessage returns timeout on exceeded message size

[jsquire]

Issue Transfer

This issue has been transferred from the Azure SDK for .NET repository, #41869. Service Bus Team: It appears that the service is not rejecting the message outright nor sending the client an error code to indicate that the message size was exceeded.

Please be aware that @erik-neumann is the author of the original issue and include them for any questions or replies.

Details

Describe the bug

We're enountering a different behavior when trying to send or schedule a message that exceeds the maximum size.

When sending the message, immediatly (or at least very quickly) a ServiceBusException is thrown: "The message (id:xyz, size:262152 bytes) is larger than is currently allowed (262144 bytes). (MessageSizeExceeded)."

When trying to schedule the message, a ServiceBusException is thrown after 10 secs: "The operation was canceled. (ServiceTimeout)". This is per default, in our production environment this timeout is reached very late because of retry configuration.

Expected behavior

Same behavior when sending or scheduling a message that exceeds allowed size, returning a ServiceBusException (MessageSizeExceeded) immediatly.

Actual behavior

ScheduleMessage returns timeout after 10 secs.

Reproduction Steps

[TestClass]
public class UnitTest1
{
    private readonly ServiceBusSender _sender;

    public UnitTest1()
    {
        var client =
            new ServiceBusClient("connectionString");
        _sender = client.CreateSender("messagesize-test");
    }

    [TestMethod]
    public async Task SendMessage()
    {
        var message = CreateMessage(262144);
        // This fails immediatly
        await _sender.SendMessageAsync(message);
    }

    [TestMethod]
    public async Task ScheduleMessage()
    {
        var message = CreateMessage(262144);
        // This fails after timeout
        await _sender.ScheduleMessageAsync(message, DateTimeOffset.Now.AddMinutes(1));
    }

    private static ServiceBusMessage CreateMessage(int size)
    {
        var payload = Encoding.ASCII.GetBytes(string.Concat(Enumerable.Repeat("0", size)));
        return new ServiceBusMessage(payload);
    }
}

Environment

Runtime Environment: OS Name: Mac OS X OS Version: 14.1 OS Platform: Darwin RID: osx-arm64 Base Path: /usr/local/share/dotnet/sdk/8.0.101/

[jsquire]

//fyi: @EldertGrootenboer

[EldertGrootenboer]

Thank you for your feedback. We have opened an investigation task for this in our backlog, and will update this issue when we have more information.

[vvamaraju]

Thank you EldertGrootenboer for helping on the reported issue. I'm the support engineer working on the subjected issue. Would like to understand if you have some update for us on the same. Thank you so much in advance.

[anqyan]

@jsquire Seems it is caused by lacking message size check in AmqpSender.ScheduleMessageInternalAsync of SDK. We have the message size check in AmqpSender.SendBatchInternalAsync, we should add the similar check to ScheduleMessageInternalAsync.

The timeout was caused by swallowing of the message size exception (thrown by ReceivingAmqpLink.OnProcessTransfer) in AmqpLink.ProcessFrame in service side code, which is by design.

[jsquire]

@anqyan. This is by design. The SDK only validates message sizes when attempting to add to ServiceBusMessageBatch. For any API that works against a message or set of messages, the client intentionally does not measure and relies on the service to enforce its limitations.

The service must perform its own validation and return an error to callers that provides them the information necessary to troubleshoot; the service cannot assume that an official Azure SDK package is what is calling it. For example, callers using Apache QPid to directly invoke the service should receive a meaningful error when the message size is exceeded.

[anqyan]

Service side investigations: Incident 471119503 : MessageSizeExceeded excepiton is not thrown for Scheduled messages.

[erik-neumann]

Hi @anqyan, is there any update on the issue? I was told it might take a couple of weeks to address the issue, and two months have passed since then.

[EldertGrootenboer]

We have brought this item in our current planning. We don't have a specific date when development will start for this, once we have more information around this, we will update this thread.