If an Azure Function that is triggered by a message on a Storage Queue throws an exception, the message will automatically be returned to the queue and retried again in the future.

In addition to specifying how soon the message will be retried, you can also configure how many times the message will be retried by editing the host.json file. By default a message will be retried 5 times before finally failing. The following host.json specifies that a message should be retried 10 times before finally failing:

Handling Poison Messages in Azure Functions

Once a message has been retried the maximum number of times, it will be considered a poisonous message, essentially that if we keep it on the queue it will “poison” the application/function and cause harm. Poison messages will be removed from the queue and placed onto a poison queue.

For example, if the queue that triggers the function is called “input-queue”, poison messages will be moved to a queue called “input-queue-poison”.

Because we know the name of the poison queue, we can process these poison messages somehow. Exactly how you choose to process these messages will depend on the application you are building.

One thing to think about is why the message may have failed:

Is the message content itself corrupted?

Is the function code itself defective/have a bug?

Were the exceptions caused by a transient error in a service the function uses?

Etc.

You could have some automated process (function) attempt to resolve the poison messages or forward them to a human to resolve (for example writing the message to database that a human can query).

Triggering an Azure Function From a Poison Message Queue

As an example, the following function retrieves messages from the “input-queue-poison” queue and writes out to table storage for a human to manually correct somehow:

By default, if an exception occurs in an Azure Function that uses a Storage Queue trigger, the message will be returned to the queue and automatically retried again in the future (up to a maximum number of times).

Notice in the preceding output, the next visible times don’t include a delay in when the message can potentially be retried.

The next visible time controls when the message will become visible to be consumed. This default value in Azure Functions is 0. You may want to change this default if you want to add some delay between message retries (for example to help prevent message loss* for transient failures).

* Eventually, failed messages will be moved to a poison message queue.

The next visible time can be configured in the host.json file (we are using Azure Functions V2 in this article):

The visibilityTimeout value represents a timespan (HH:MM:SS) to wait before a message becomes visible next time, in the preceding configuration, 30 seconds. Running again with this new configuration, the following output can be seen:

In the preceding code, the inputQueueItem represents the content of the message that triggered the function.

If you want additional information about the queue message item itself, rather than use a string you can use CloudQueueMessage. Doing this gives you access to the metadata about the queue message including the following:

Message ID

Time message was inserted into queue

Time the message expires

How many times the message has been dequeued (i.e. read off the queue )*

Message next visible time

Message pop receipt

* A message can be returned to the queue if an exception occurs during execution of the function, this will increment the dequeue count.

In addition to the message metadata, you can still get the message content either as a string or byte array using the AsString or AsBytes properties respectively:

When working with Azure Functions in C# (specifically Azure Functions V2 in this article) you can specify bindings with hard-coded literal values.

For example, the following function has a queue trigger that is reading messages from a queue called “input-queue”, an output queue binding writing messages to “output-queue”, and a blob storage binding to write blobs to “audit/{rand-guid}”:

Notice the “in”, “out”, and “blobout” configuration elements that map to "%in%", "%out%", and "%blobout%”.

Configuring Bindings in Azure

Once deployed and running in Azure, these settings will need to be present in the Function App Application Settings as the following screenshot demonstrates:

Now if you want to modify the queue names or blob path you can simply change the values in configuration. It should be noted that you may have to restart the Function App for the changes to take effect. You will also need to manage the switch to new queues, blobs, etc.such as what to do if after the change there are still some messages in the original input queue, etc, etc.

When the result you want to check is a collection, you can use NUnit to assert that it has the expected number of items or is empty, that all items are unique, that specific items do/not exist, and that items exist that satisfy some condition or predicate.

When asserting on equality using the EqualConstraint you may not always get the behaviour you want depending on what objects are being asserted on. This can be influenced by whether or not the objects are value or reference types and if the type implements or overrides methods such as IEquatable<T> or object.Equals overrides.

Asserting That Two References Point to the Same Object with NUnit

If you want to assert that 2 object references point to the same object you can use the SameAsConstraint:

Assert.That(p1, Is.SameAs(p2)); // fail, p1 and p2 point to different objects in memory
Person p3 = p1;
Assert.That(p3, Is.SameAs(p1)); // pass, p3 and p1 point to same object in memory
Assert.That(p3, Is.Not.SameAs(p2)); // pass, p3 and p2 point to different objects in memory

Customizing Equality Asserts with NUnit

There are a number of ways to influence how NUnit performs equality assertions including implementing IEquatable<T>:

Whilst I’m not personally a fan of New Year’s Resolutions, preferring instead to adopt a mindset of continuous improvement, the end of a calendar year is as good a time as any to do a 12 month retrospective and think about the future.

Below are a number of resources you may find helpful to make 2019 your best year yet, along with some of the things I’m currently learning/implementing in my quest for personal development.

2018 Book List

These are some of the books I read in 2018 that I found helpful and that have influenced my thinking and personal growth:

The Inner Game of Tennis (W. Timothy Gallwey). More about physical development/performance but the ideas transcend into anything you want to learn.

Man's Search for Meaning (Viktor E. Frankl). Harrowing account of Nazi concentration camps infused with what it means to have real meaning in your life.

Principles: Life and Work (Ray Dalio). Ray Dalio is the founder of one of the biggest and highest performing hedge funds in the world, this book shows the life and work principles the author has developed and also introduces the fascinating idea that you can run your life based on a set of your own written down principles.

This article assumes you have set up the Tizen/Visual Studio development environment as outlined in this previous article.

Installing the Watch Emulator

The first step is to install the relevant emulator so you don’t need a physical Samsung Galaxy Watch. To do this open Visual Studio and click Tools –> Tizen –> Tizen Emulator Manager

This will bring up the Emulator Manager, click the Create button, then Download new image, check the WEARABLE profile, and click OK. This will open the Package Manager and download the emulator.

Once the installation is complete, if you open the Emulator Manager, select Wearable-circle and click Launch you should see the watch emulator load as shown in the following screenshot:

Creating a Watch Project

In Visual Studio, create a new Tizen Wearable Xaml App project which comes under the Tizen 5.0 section.

Once the project is created and the with the emulator running, click the play button in Visual Studio (this will be something like “W-5.0-circle-x86…” ).

The app will build and be deployed to the emulator – you may have to manually switch back to the emulator if it isn’t brought to the foreground automatically. You should now see the emulator with the text “Welcome to Xamarin.Forms!”.

The preceding code essentially allows the user to specify how happy they are using a slider, and then hit the Go button. This button makes an HTTP POST to a URL, in this example the URL is a Microsoft Flow HTTP request trigger.

The flow is shown in the following screenshot, it essentially takes the JSON data in the HTTP POST, uses the HappyLevel JSON value and sends a mobile notification to the Flow app on my iPhone.

Testing the App

To test the app, run it in Visual Studio:

Tapping the Go button will make the HTTP request and initiate the Microsoft Flow, and after a few moments, the notification being sent to the phone:

For any sufficiently complex application you’re building it's likely that the above things, and more, will be beneficial.

The problem is if you’re not doing any of these things and you feel overwhelmed where do you start?

You start where you're at.

build on each success with subsequent success

I remember watching Ray Mears on TV once and he used the acronym STOP to remember what to do if you get lost or stranded:

(S)top

(T)hink

(O)rient

(P)lan

If you feel overwhelmed this may be a useful acronym to help you start where you're at.

Accepting where you are now and starting where you're at can help remove negative feelings and the feeling of being overwhelmed and not being "good enough" at your job.

This of course doesn't mean that you should accept unprofessional practices and not try to improve things, it simply means acknowledging without judgement where you are now and then moving forward to improve things for the future.

You can start with the "big rocks", the more important or foundational things such as making sure you're using adequate source control. Maybe then move to implementing a basic continuous integration build. Maybe then start to add some automated tests, etc. etc.

Do things incrementally and build on each success with subsequent success.

With over 15 years experience, Jason Roberts is a former 5-time Microsoft .NET MVP, freelance developer, writer, and Pluralsight course author. He has written multiple books and is an open source contributor. In addition to enterprise software development, he has also designed and developed both Windows Phone and Windows Store apps.