Search code examples
azureexceptionazure-functionsservicebusdead-letter

Add additional information to Azure Function Dead-letter-queue if exception happened

I was writing a Azure function with service bus trigger while I noticed that if there is any exception occurred, after certain times of built-in retries, it will put the incoming message into the dead letter queue (or called poison-queue? in microsoft document, however, I am not able to get or add any additional information from the DLQ. For example, I am trying to convert 1000 record but 1 of the record convert failed due to invalid data type, then the exception throws and my function ends its work, what the exception looks like, why and when it generated or what would my data looks like when exception happened were all not be able to capture in DLQ message.

I tried to customized the exception object to add more information but seems like it won't affect the way that message sent to the dead-letter-queue. Is that how dead-letter-queue designed that it would only move the message from standard queue to DLQ when exception happened?

What would be the best way that I can handle my exception within the azure function? According to Microsoft we recommend that you use try-catch blocks in your function code to catch any errors., should I put my exception in another queue and let another service to take a look or handle from the other side?

Solution

  • We've run into this problem as well. We solved it by putting our message in an envelope that had a DequeueCount and an array of Exceptions. When a message is dequeued, we increment the dequeue count within the Azure Function. If an exception occurs, we do the following:

    1. In the catch block, we increment the dequeue count and add the full exception to the exceptions array.
    2. Increment the dequeue count and explicitly add the message back to the queue.

    This way, the message carries the dequeue count and a history of any exceptions that've occurred.

    When we dequeue a message, we check the dequeue count. If it's above our threshold, we explicitly deadletter the message.

    This way, the deadlettered message will contain the full exception history. You can follow this pattern to save any logging info you want to the message so that you can see it all if it ends up being deadlettered.