Azure service bus - message going straight to dead letter queue
Asked Answered
C

2

5

I have the following code to send messages to the bus:

var queueClient = new QueueClient(ServiceBusConnectionString, QueueName);

var message = new Message(poco.SerializeToBytes());

await queueClient.SendAsync(message);

But they seem to be going straight into the DEAD-LETTER MESSAGE COUNT:

enter image description here

I have also created an Azure function which will pick messages up:

    [FunctionName("ServiceBusFunction")]
    public static void Run([ServiceBusTrigger("schedule", AccessRights.Listen, Connection = "ServiceBusConnection")]byte[] myQueueItem, TraceWriter log)
    {
        log.Info($"C# ServiceBus queue trigger function processed message: {myQueueItem}");
    }

When I turn the function off, the messages were go into the ACTIVE MESSAGE COUNT before I created this function. I've tried running the function locally and the function was not being hit. I feel like I'm missing something fundamental in terms of picking up messages on the bus from a function?

Ceyx answered 1/3, 2018 at 14:27 Comment(1)
Please check the max delivery count properly of the queue in question. This determines when a message should be sent to dead letter queue. Also check the delivery count property on the message. This tells you how many times a message has been processed. Please update your question with these values.Biddable
S
8

If you go to your Function App logs, you'll probably see errors like

Exception binding parameter 'myQueueItem'. Microsoft.Azure.WebJobs.ServiceBus: The BrokeredMessage with ContentType 'null' failed to deserialize to a byte[] with the message: 'There was an error deserializing the object of type System.Byte[]. The input source is not correctly formatted.'. System.Runtime.Serialization: There was an error deserializing the object of type System.Byte[]. The input source is not correctly formatted. System.Runtime.Serialization: The input source is not correctly formatted. 2018-03-01T15:14:41.578

Function App tries to process your message 10 times (default), and then puts it into DLQ with

Message could not be consumed after 10 delivery attempts.

The problem has to do with the fact that you are sending messages from "the new" .NET Standard Service Bus client, while Function App v1 is using "the old" BrokeredMessage-based client. And they are not compatible on binary level, see this issue.

Until Function App v2 including Service Bus binding is ready, you should better use the old Service Bus client to send messages. If you have to use the new client, see some workarounds in the issue linked above, e.g. this comment.

Sweettalk answered 1/3, 2018 at 15:17 Comment(1)
Ah. That makes total sense. Thanks.Ceyx
E
-2

You can see the reason a message was sent to a DLQ. You can access the servicebus>>topic>>subscription>>servicebus explorer>>dead-letter>>peek from start>>Select a message>> click in message properties...

Then you will see the reason it went to DLQ and so, take the actions to avoid that :)

Emalee answered 8/11, 2022 at 20:4 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.