Monthly Archives: February 2022

Reading an Azure Dead Letter Queue with Azure.Messaging.ServiceBus

Some time ago, I wrote about how you can read the dead letter queue. I also wrote this post on the evolution of Azure Service Bus libraries.

By way of a recap, a Dead Letter Queue is a sub queue that allows for a message that would otherwise clog up a queue (for example, it can’t be processed for some reason) to go to the dead letter queue and be removed from processing.

In this post, I’ll cover how you can read a dead letter queue using the new Azure.Messaging.ServiceBus library.

Force a Dead Letter Message

There are basically two ways that a message can end up in a dead letter queue: either it breaks the rules (too many retries, too many redirects, etc.), or it is explicitly placed in a dead letter queue. To do the latter, the process is as follows:

            var serviceBusClient = new ServiceBusClient(connectionString);
            var messageReceiver = serviceBusClient.CreateReceiver(QUEUE_NAME);
            var message = await messageReceiver.ReceiveMessageAsync();

            string messageBody = Encoding.UTF8.GetString(message.Body);

            await messageReceiver.DeadLetterMessageAsync(message, "Really bad message");

The main difference here (other than that the previous method was DeadLetterAsync) is that you pass the entire message, rather than just the lock token.

Reading a Dead Letter Message

There’s a few quirks here – firstly, the dead letter reason, delivery count, etc. were part of an array known as SystemProperties, whereas they are now just properties – which does make them far more accessible and discoverable. Here’s the code to read the dead letter queue:

            var serviceBusClient = new ServiceBusClient(connectionString);
            var deadLetterReceiver = serviceBusClient.CreateReceiver(FormatDeadLetterPath());
            
            var message = await deadLetterReceiver.ReceiveMessageAsync();

            string messageBody = Encoding.UTF8.GetString(message.Body);

            Console.WriteLine("Message received: {0}", messageBody);

            // Previous versions had these as properties
            // https://www.pmichaels.net/2021/01/23/read-the-dead-letter-queue/
            if (!string.IsNullOrWhiteSpace(message.DeadLetterReason))
            {
                Console.WriteLine("Reason: {0} ", message.DeadLetterReason);
            }
            if (!string.IsNullOrWhiteSpace(message.DeadLetterErrorDescription))
            {
                Console.WriteLine("Description: {0} ", message.DeadLetterErrorDescription);
            }

            Console.WriteLine($"Message {message.MessageId} ({messageBody}) had a delivery count of {message.DeliveryCount}");

Again, most of the changes are simply naming. It’s worth mentioning the FormatDeadLetterPath() function. This was previously part of a static helper class EntityNameHelper; here, I’ve tried to replicate that behaviour locally (as it seems to have been removed):

        private static string QUEUE_NAME = "dead-letter-demo";
        private static string DEAD_LETTER_PATH = "$deadletterqueue";
        
        static string FormatDeadLetterPath() =>
            $"{QUEUE_NAME}/{DEAD_LETTER_PATH}";

Resubmitting a Dead Letter Message

This is something that I covered in my original post on this. It’s not inbuilt behaviour – but you basically copy the message and re-submit. In fact, this is much, much easier now:

            var serviceBusClient = new ServiceBusClient(connectionString);

            var deadLetterReceiver = serviceBusClient.CreateReceiver(FormatDeadLetterPath());
            var sender = serviceBusClient.CreateSender(QUEUE_NAME);

            var deadLetterMessage = await deadLetterReceiver.ReceiveMessageAsync();            

            using var scope = new TransactionScope(TransactionScopeAsyncFlowOption.Enabled);

            var resubmitMessage = new ServiceBusMessage(deadLetterMessage);
            await sender.SendMessageAsync(resubmitMessage);
            //throw new Exception("aa"); // - to prove the transaction
            await deadLetterReceiver.CompleteMessageAsync(deadLetterMessage);

            scope.Complete();            

Most of what’s here has previously been covered; the old Message.Clone is now much neater (but slightly less obvious) in that you simply pass the old method in as a constructor parameter. Because the Dead Letter Reason, et al, are now properties, there’s no longer a need to manually deal with them not getting copied across.

The transaction simply checks that either the dead letter message is correctly re-submitted, or it remains a dead letter.

Summary

The new library makes the code much more concise and discoverable. We’ve seen how to force a dead letter; how to receive and view the contents of the Dead Letter Queue, and finally, how to resubmit a dead lettered message.

Isolated Azure Function in .Net 6

I’ve recently been working with Azure Isolated Functions for .Net 6. This is a kind of getting started guide – especially if you’re coming across from non-isolated.

What’s an Isolated Function

As is explained here, an isolated function is a function that runs out of process and self-hosted. Previously, there were issues with dependency conflicts because you were married to the function host.

What’s the Difference Between an Isolated an Non-Isolated Function?

A non-isolated function can have just one file in the project; for example:

And in that file, you can have a single method, decorated with a Function attribute:

        [FunctionName("Function1")]
        public async Task<HttpResponseData> Run(. . .

However, for an Isolated Function, you’ll need a Program.cs, with something along the lines of the following as a minimum:

        public static async Task Main(string[] args)
        {
            var host = new HostBuilder()
                .ConfigureFunctionsWorkerDefaults()
                .Build();

            await host.RunAsync();
        }

Further, the dependency libraries change; Isolated Functions use the following libraries (these obviously depend slightly on your bindings, but are a good start):

  <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Abstractions" Version="1.1.0" />	 
  <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.3.0" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.6.0" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.0.13" />

Finally, you’ll need to change your decorator to:

[Function("Function1")]

From:

[FunctionName("Function1")]

FunctionName uses the old WebJobs namespace.

Some possible errors…

At least one binding must be declared.

This error typically happens in the following scenario: the method has a [Function] decorator, but within the method signature, there are no valid Bindings – that is, nothing that the Azure Function ecosystem understands. For example; the following signature would give that error:

[Function("Function1")]
public void MyFunc()
{
}

Specified condition “$(SelfContained)” evaluates to “” instead of a boolean.

For this, you need to specify the output type to be an executable:

<PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <OutputType>Exe</OutputType>
    <Nullable>enable</Nullable>
</PropertyGroup>

Xunit Tests Won’t Run After Upgrade to .Net 6

Some time ago, while trying to get .Net Core 3.1 to work with Xunit, I discovered that 2.4.1 was the correct library to use for xunit.runner.visualstudio. At the time, I wasn’t sure why this was the case.

Recently, after upgrading an Azure Function to .Net 6 from 5, I came across almost the reverse problem. It turns out that 2.4.3 actually works fine for xunit.runner.visualstudio, however, you need to include the following library as well:

Microsoft.NET.Test.Sdk

For .Net 6, if you want to run Xunit, then you need the following libraries:

<ItemGroup>

	<PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.0.0" />

	<PackageReference Include="xunit" Version="2.4.1" />
	<PackageReference Include="xunit.runner.console" Version="2.4.1" />
	<PackageReference Include="xunit.runner.visualstudio" Version="2.4.3" />
</ItemGroup>

References

https://stackoverflow.com/questions/69972184/xunit-tests-no-longer-working-after-upgrade-from-net-5-to-net-6-q-a