We've all had to roll out some form of feature management, whether it was static values in an appsettings.json file or a fully managed service with feature management based on various rules.

In this post we'll be unpacking the Azure App Configuration Feature Management a little bit, using a Targeted filter and creating a custom ITargetingContextAccessor implementation.

You can check out my feature_flags repository and play around if you want.
It contains all the code examples for this post.
The repo is deployable to Azure, just call azd up or run it locally if you have an App Configuration resource already.

Introduction​

Azure has had App Configuration available for quite some time now, and I knew it provided Feature Management out of the box, but I wanted to see if it could provide a more dynamic experience than a Feature On/Off switch, or a complex json blob with a custom filter.

I had a little dive into the App Configuration Feature Management Documentation and was pleasantly surprised with the Targeted filter type.

When I say dynamic experience - I tried to see if I could manage feature flags at multiple levels, let's say enable it for certain users, as well as certain groups (or companies, modules, countries, you get it...)

The Azure App Configuration Feature Flag with a Targeted filter allowed me exactly that.

• A simple but meaningful UI that allowed me to visually enable or disable features for certain users or groups.
• RBAC to allow fine grained control on who can make changes to the feature flags
• Configurable refresh intervals based on my application's needs
• An easy to implement Interface to allow custom feature evaluation

Obviously there are loads more benefits, these were the top 4 requirements I wanted to tick off in this post.

The start​

Microsoft has some really good documentation on how to get started with Feature Flags and Targeted filters.

Microsoft describes it as a strategy that you can use to progressively roll out new features by targeting a known group of uniquely identifiable entities.

You can read up more about it in the documentation, but I wanted to share an important part of how this filter work - the evaluation flow.

This shows you how the users and groups you configure within the Targeted filter will be evaluated.
This was really cool to see and slightly more than I was expecting!

I don't see myself needing a feature flag where I want to exclude users, exclude groups, Include users, include groups, and have a percentage weight to it.
My requirements stopped at

• on for everyone, but exclude these users and groups and
• off for everyone, but include these users and groups

Next is the Default Percentage slider - this is great because you can enable a feature, but set the default percentage of entities that it's on for.
This matches my need of a feature being enabled - but on for everyone by default, or off for everyone by default

Configuring Services

Okay let's finally dive into my code and see how I configured everything.

var builder = WebApplication.CreateBuilder(args);

// Retrieve the endpoint
string endpoint = builder.Configuration.GetValue<string>("Endpoints:AppConfiguration")
    ?? throw new InvalidOperationException("The setting `Endpoints:AppConfiguration` was not found.");

// Load configuration from Azure App Configuration 
builder.Configuration.AddAzureAppConfiguration(options =>
{
    options.Connect(new Uri(endpoint), new DefaultAzureCredential());
    options.UseFeatureFlags(options =>
    {
        options.SetRefreshInterval(TimeSpan.FromSeconds(30));
    });
});

builder.Services.AddFeatureManagement()
    .WithTargeting();

//register the AzureAppConfigurationRefresherProvider services that's required for automatic refresh.
builder.Services.AddAzureAppConfiguration();

This looks pretty standard and matches what the documentation provided. So why the long blog post?

You can see I added the Azure App Configuration and set the RefreshInterval.
Although the default is 30 seconds anyway, I like to set thes values explicitly.
It creates visibility for myself or the team - since not everyone has the same context.

When initially testing it out it wasn't obvious to me yet, but builder.Services.AddFeatureManagement() registered the services as Singleton services. More about it later.

The builder.Services.AddAzureAppConfiguration() ensures the RefreshProvider is loaded which will be required by the middleware that I register next.

Middleware and endpoints

var app = builder.Build();

//middleware that will call refresh based on the refresh interval
app.UseAzureAppConfiguration();

app.MapGet("/feature-flag", async (IFeatureManager featureManager) =>
{

    if (await featureManager.IsEnabledAsync("Demo"))
    {
        return Results.Ok("Feature Demo is enabled for you");
    }

    return Results.Ok("Feature Demo is disabled for you");
});


app.MapGet("/enabled-flags", async (IFeatureManagerSnapshot featureManager) =>
{

    var enabledFeatures = new List<string>();
    await foreach (var feature in featureManager.GetFeatureNamesAsync())
    {
        if (await featureManager.IsEnabledAsync(feature))
        {
            enabledFeatures.Add(feature);
        }
    }
    return Results.Ok(enabledFeatures);

});

app.Run();

The app.UseAzureAppConfiguration(); added the middleware that will actually refresh the feature flag values.

Interestingly enough, this doesn't mean that the feature flags will refresh every 30 seconds (or on your Refresh Interval) - it actually just means that, at most, it will refresh every 30 seconds.
It can refresh at a much slower rate if there is no traffic and the middleware isn't triggered.
This prevents the service from blasting the App Configuration unnecessary and slowing down your services.
You can also remove the middleware and refresh the feature flags on demand.

The first endpoint /feature-flag checks if I'm enabled for the Demo feature. Pretty simple.

The second endpoint /enabled-flags will return all the feature flags I'm enabled for.
This was only for testing purposes. It's probably better than checking each feature flag independently over numerous network calls, but could also be really heavy if I have a large amount of feature flags and complex or slow evaluation logic.

The challenges​

• Out of the box, the Targeted filter comes with a default Context Accessor that works by utilizing the HttpContext.User.Identity.Name as the UserId and the HttpContext.User.Claims of type Role for Groups - This is great if you're using Entra ID or other common Identity Providers.
  But often Authentication and Authorization is split, or you want to roll out features based on some other user related value like location, age, net worth, etc.
• Case sensitive evaluation: Turns out the Targeted filter is case sensitive by default. I'm not a fan and I'm not dealing with the headache of debugging test@test.com vs Test@test.com
• Singleton services: The Feature Management services are added as Singleton services, so it might be a problem if you want to use scoped services in your custom implementation.
  It does make sense why it's registered as Singleton services, feature flags are "configuration" and shouldn't change per request, Singletons are more performant to load and it will improve consistency (if you have a high amount of traffic, scoped services might end up having different values - although you shouldn't be relying on feature flags if you need that level of consistency in my opinion)

The solution​

I'll start by addressing the case sensitive evaluation.

If you want to have case insensitive evaluation, you need to configure the TargetingEvaluationOptions. Easy as that.

//case insensitive comparison for FeatureManager.
builder.Services.Configure<TargetingEvaluationOptions>(options =>
{
    options.IgnoreCase = true;
});

If you need to use Scoped services for your FeatureManagement, you can change your service registration to the following:

builder.Services.AddScopedFeatureManagement()
    .WithTargeting();

Now my IFeatureManager is registered as a Scoped service and can use other Scoped services.

Just a note on the Scoped vs Singleton services, if I call await featureManager.IsEnabledAsync("Demo") twice, it will evaluate the feature flag twice. There is no magic in the Feature Manager that will cache the result or anything differently between the Scoped vs Singleton instances.

Custom feature flag evaluation using ITargetingContextAccessor
Now this was the interesting part.
Creating your own implementation of the interface allows you to inject any context you want to evaluate the user or groups parameters.

The ITargetingContextAccessor Interface is straight forward and has a single method ValueTask<TargetingContext> GetContextAsync();
The TargetingContext class has two properties to represent the UserId and a list of groups.

For this example, I create a UserService that will return some user related information, more specifically, companies I have access to.

public class UserService : IUserService
{
    //Get user related information
    public User GetCurrentUser()
    {
        var groups = new List<Companies>
        {
            new Companies(new Guid("A9726B81-F306-450B-B26B-0EB061700633"), "CompanyA"),
            new Companies(new Guid("5A1230AD-48FC-461A-B44F-1D3477974664"), "CompanyB"),
            new Companies(new Guid("835DAB0A-8378-44D2-8F93-9FC49D3D7849"), "CompanyX")
        };
        return new User(new Guid("41EAA244-9939-48D4-9820-B0B41F716F81"), "MockUser", groups);
    }
}

public record User(Guid ID, string Name, List<Companies> Companies);
public record Companies(Guid ID, string Name);

I then created my custom implementation of the ITargetingContextAccessor interface

public class DemoTargetingContextAccessor : ITargetingContextAccessor
{
    private readonly IUserService _userService;

    public DemoTargetingContextAccessor(IUserService userService)
    {
        _userService = userService;
    }

    public ValueTask<TargetingContext> GetContextAsync()
    {
        var user = _userService.GetCurrentUser();
        var targetingContext = new TargetingContext
        {
            UserId = user.Name.ToString(),
            Groups = user.Companies.Select(x => x.Name.ToString())
        };

        return new ValueTask<TargetingContext>(targetingContext);
    }
}

In this example I used the User Name and Company Name values to populate the TargetingContext - so in my Targeted filter in the App Configuration I can enter nice human readable values like CompanyX, or Kyle, etc.
I could have easily used the ID or any other values, and configured the Targeted filter accordingly.

Below is an example where I registered a Targeted filter with the Default Percentage set to 0 - so by default off for everyone, and I added mockuser to the Include Users - so this filter is only enabled for the single user.

Lastly, I registered the new services and I was done!

builder.Services.AddScoped<IUserService, UserService>();
builder.Services.AddScopedFeatureManagement()
    .WithTargeting<DemoTargetingContextAccessor>();

To test the feature management, I configured a few different features:

• Feature Demo1 enabled for my mockuser
• Feature Demo2 enabled for companyz
• Feature Demo3 disabled for mockuser but enabled for companyb
• Feature Demo4 enabled with an empty Target filter but 100% allocation

And here is the response from my /enabled-flags endpoint

Some interesting bits​

Remember earlier when I said that feature flags will always be evaluated every time when calling await featureManager.IsEnabledAsync("Demo") ?

The DefaultHttpTargetingContextAccessor comes with a really nice pattern where it caches the result for the duration of the request. A similar optimization should be considered if you want to create your own implementation.

HttpContext httpContext = _httpContextAccessor.HttpContext;

// Try cache lookup
if (httpContext.Items.TryGetValue(_cacheKey, out object value))
{
    return new ValueTask<TargetingContext>((TargetingContext)value);
}

// rest of the code

// Cache for subsequent lookup
httpContext.Items[_cacheKey] = targetingContext;

When overriding the users in the Targeting filter, there is a warning that feature flags have a 10kb limit.

It's not really clear from that message if it only applies to filtering on users, or what exactly falls under that limit for the Targeted filter, and the same message doesn't appear anywhere else on the filter - but looking at the App Configuration FAQs it looks like it's a limit for a single key-value, which makes me believe it's for an entire "Feature Flag"

Looking at the structure for a Feature Flag we can do some simple math to calculate how many values you can filter on with a 10kb limit.

{
	"id": "demo",
	"description": "",
	"enabled": true,
	"conditions": {
		"client_filters": [
			{
				"name": "Microsoft.Targeting",
				"parameters": {
					"Audience": {
						"Users": [
							"User1",
							"User2"
						],
						"Groups": [
							{
								"Name": "CompanyA",
								"RolloutPercentage": 100
							},
							{
								"Name": "CompanyB",
								"RolloutPercentage": 100
							}
						],
						"DefaultRolloutPercentage": 0
					}
				}
			}
		]
	}
}

Let's assume you have really long names and a user filter uses 50 characters and a group filter uses 100 characters.

Each user = 50 characters (plus quotes and commas). Let’s round to 55 bytes per user.
10240 / 55 = 186 users

Each group = 100 characters (plus JSON overhead like {"Name":"...","RolloutPercentage":100}). That’s closer to 130 bytes per group.
10240 / 130 = 78 groups

That's still a good number of users or groups that you can apply the filter to even if they have reeeeally long names.
With the rest of the json data in the structure I would be cautious going over 75 groups or 180 users - but you do the math

Try it out​

Want to play around? You can check out my feature_flags repository to get started.
It contains all the code examples for this post.
The repo is deployable to Azure, just call azd up or run it locally if you already have an App Configuration resource.

I want to share a lesson I learned about burnout, from my sister's swimming!

We've all felt it, stretched too thin, juggling too many things, pushing too hard - Burnout is tricky, it creeps up on you, and by the time your realize it, you're already drained.

Burnout can happen for a bunch of different reasons, at work you might be wearing too many different hats and trying to fill too many gaps, entering a stressful period or working, taking on too much work for an unrealistic deadline. It can even be as simple as you've just been working too long without a break.
At home you might have personal circumstances that require more of you than usual, stressful life events, physical changes or stressors - we've all experienced what a few consecutive days of bad sleep can do to us 😂

My sister told me a story of how her swim training made the proverbial penny drop on how burnout can look without you even noticing it.

The lesson...

My sister joined a swim club a while ago, during one particular session, as they approached the back end - they had to do 4 slow laps, 4 medium laps and end with 4 laps swimming full out.
Great, she thought, little bit of planning and she can smash this!
She was swimming along nicely in the first 4 laps, conserving her energy, feeling good.
The next 4 laps she started pushing a bit, she felt like she was in her sweet spot, getting a bit tired but manageable, it's only 4 laps, how tired could it make her?
Next was the hard laps, she pushed her hardest, it felt like she was giving everything, kicking extra hard and being ultra focused on her effort, her technique, her breathing, she was absolutely smashing it - or so she thought.

Afterwards when she compared her times, her last 4 laps when she gave her everything - were slower than her first 4 slow laps 😦

This is when burnout truly made sense to her - a few minutes in a pool painted a picture that we often don't see in the workplace because burnout doesn't usually happen overnight, it's days, weeks or months.
What happened was she was working at a maintainable pace, she was happy, stressors were normal but increasing. As she pushed harder, she had to keep on pushing harder, she gave her best but by the end her best was worse than her barely trying. That's the thing about burnout, it takes so much more from you to deal with the basics, nevermind performing well.

Her story really made me think and reflect on my own experiences (and sometimes bad habits)

I remember starting a new project, and every little bump in the road upset me, I started to take it personally, pushed even harder and it got to a point where it affected me at home, my sleep, my physical health. I took a week off, focused on myself, enjoying every day and spending quality time with my family. When I got back to work, nothing burned down, the project was still on track, some of the same bumps were still there - but they were easy to deal with and no problem at all 😂

I'd like to leave you with this.

Have you been feeling frustrated, your goal always just out of reach, like all you need to do is push a little bit harder, and this is the 3rd time you're just pushing harder? Have you considered that maybe you're on your last 4 laps and you're burned out?

Sometimes the best way forward isn't pushing harder, it's taking a break.

I built something cool! AI Agents repository - an AI agent that performs automated code reviews.

Like everyone, I've been playing with AI Agents for a while now. I'm lucky enough that Investec allows, and encourages, us to adopt AI and use it to our advantage. But I've always thought there should be more to it. I wanted to see the 10x it promised.

Recently, I've been challenging myself whether I'm only using AI where I'm encouraged to use it - like GitHub Copilot - or if we can change our perspective and use it to impact the entire team or organisation.

The Evolution of the Console App​

Almost everyone reading this has probably built a console app - some probably hundreds of console apps 😀

I've been thinking about how Agents could be the next evolution of console apps we build.

I don't mean using Agents to just search for certain keywords in a log file or build a CSV. Those are perfectly suited to a Console App. I mean in the sense that it should take me minutes or just a few hours to automate a very manual, repetitive, organization-wide task.

The Agent PR Experiment​

I decided to build an AI agent to challenge my thinking: Could I automate a code review?

"But Kyle, you love doing code reviews, it's part of what you enjoy about your job" - Yes and No! I love doing a code review to provide valuable feedback, it's also how I get to share my knowledge, but this also takes up a lot of time, and you don't always have time to do a code review when someone wants one.

The result is an AI Agent that can perform a code review and leave feedback, a Multi-Agent workflow that performs comprehensive code reviews on pull requests from GitHub.

In the link I shared, I spent a few short hours spinning up a basic (and I mean really basic) Agent in Python that can perform a code review. But the results were pretty encouraging!

Building the Agent: With the same freedom as building a console app - fast and furious!​

The Architecture​

I tried to keep the design simple and let the agent evolve to fit my needs, no real pre-planning.
I know with AI Agents that having multiple agents focus on smaller sub tasks outperforms a single agent trying to do everything.

⭐ Multi-Agent Review System (async tasks)
I ended up with three different agents so that they could focus on their specific tasks:

• Style Reviewer: The one that catches all the indentation and naming stuff that makes me go 😒
• Security Reviewer: Uses OWASP Top 10 to spot the scary stuff
• Summarizer: Takes all the feedback and makes it actually useful

I figured this would be enough to see if I could get valuable feedback from the workflow, and identify any improvements I'd want to make in the future.

⭐ StateGraph (Static Dictionary)

LangGraph is a Python framework for building stateful, multi-agent workflows.
StateGraph enables the state management and execution flow.

I really enjoyed spending time on thinking about this process, using LangGraph's StateGraph, and how I would use this in a "real world" scenario.
The interesting part was that just using in-memory state was good enough, and that the agent flow required was really simple.
This agent is supposed to execute fast, doesn't require any async execution or human in the loop.
A pity, I would have loved to throw in CosmosDB to store the state and some complex agent flows.

One of the concepts I wanted to test was to see if I could make the reviews more meaningful by passing in an instruction file from the repository linked to the code review.
Like mentioned above, I just stored the the state in memory - and as agents completed I stored their state in the same object to be used by the Summarizer agent.

⭐ Local development & cloud deployment
When you build a console app, you run it locally, but the truly special ones might make it to a different environment, so I wanted to test both, and for this scenario it made sense to support cloud deployments - it wouldn't make sense to run an agent locally for code reviews.

• Local Development: Ollama with phi4-mini - free and fast for getting started
• Cloud Deployment: Azure OpenAI with GPT-4o - to be honest, this was the model that came out of the box with the azd template so why not.

⭐ Secure~ish Design
Security comes out of the box for any cloud platforms and I made use of the basics

• Azure Key Vault for secrets
• Managed Identity to access Azure resources

Some of the things I didn't do:

• Api authentication - Allowing unauthorized users to call your api is 99% of times a very bad idea. It opens up the api to spamming innocent pull requests with code reviews But Kyle, you can trust strangers on the internet, no? and in the process leaving you with a huge bill and embarrassment. This being a POC, Authentication wasn't something that I wanted to prove, so I skipped it for now.
• Prompt injection protection - and this is where I should probably spend some more time. Due to the design of the agent, it tries to read a "pr_instructions.md" file from the repo it's about to review for custom instructions. My first thought was that this should be okay, considering you're reviewing your own code, you would only be injecting yourself - but security is only as strong as your weakest link and if a malicious user got access to the PR agent, it could probably do some real damage.
  Here is an example of a "pr_instructions.md" file I used to give my reviewers more context.
  

What I learned​

What really surprised me while building the agent was how easy it was to get something up and running really quickly.
And this probably isn't specific to Python and LangGraph, it could have been C# and Semantic Kernel, or AWS instead of Azure. Much like a console app, these tools all feel well supported, easy to use and fit right into your current ecosystem.
I didn't have to dig deep or search far to get something working, all I had to do was try.

Some more AI Agent related lessons that I learned:

• All LLMs aren't created equal - There are real differences in their responses, even with just the default settings. To get real value out of an AI Agent, you probably need to tweak its settings a bit.
• Your agents can be more specific than you think - While I was creating this proof of concept I kept on thinking about adding more instructions or context to an agent, and the thoughts quickly turned to "what different agents could I add". I'm lucky that I work with some incredibly smart engineers, and maybe I could try and mimic some of them, instead of a more generic "Security Reviewer" agent.
• Fine tuning your prompts really matter - I played with a few different prompts and they evolved over time. I wish I saved my first and last prompt (or code reviews) to show the difference. From a complete failure to something providing real value.
  

What's next for my code review agent.​

• Improving the context with function calling - When I do a code review I often look at the rest of the file to gain more context. Loading all the files into the prompt from the start seems like a bad idea, but using function calling to load specific files if they require more context might be a great way of allowing the Agents to perform better code reviews.
• Recreating a team member - One idea I want to test is recreating one of our engineers by loading all of their previous code reviews into a Vector Database and using Semantic Search to retreive specific reviews based on the engineer and the file, and exposing it to the Agent. If we want value out of these code reviews, how about giving it the context of the best reviewers in the team.

Vector Database is a type of database that stores text or code as numbers so a computer can quickly find things with similar meaning.
Semantic Serach is a search method that finds results based on meaning and context rather than just keyword matches.

Final Thoughts​

Most organisations have had to migrate from one code repository to another, from GitHub to Azure DevOps, from BitBucket to GitHub, from SVN to where ever.
Most organisations also had to rebuild their build and release pipelines from... you get the picture.

Along with code reviews, these are all very repeatable tasks that follow the same patterns and in my opinion are ideal for AI Agents.
If you're challenged with rebuilding 200 pipelines, will it be worth spending 10% of the time creating an Agent and letting it do all the hard work?

I think I proved to some degree that AI Agents can be a valuable tool in the everyday developer playbook. It takes a bit of time to set up your first agent, the next one is faster, the third one feels like a real console app.
For organisations that require more governance, I can see setting up a sandbox environment or template with built-in auditing and security being a good way to enable the organisations to iterate faster in a safe manner.

Try it out​

Want to dive deeper? Check out the AI Agents repository and let me know what you build! I'd love to hear about your experiments. The repo is deployable to Azure. Just call azd up or run it locally with Ollama.

I made something cool! budgetspeech

I love personal finance, sometimes it can be hard, sometimes it can be stressful, but it's something all of us have to deal with in some capacity.

My wife and I have a bi-weekly meeting called ⭐ Budget Speech ⭐ - Where either of us get to be the Minister of Finance for the evening and, you know, give the Budget Speech :satisfied:

We have a big Excel document with all our budgets for different expenses and we track it throughout the month. This workes pretty great and we can be really specific about which expenses gets allocated against which category. This way we're always on the same page whether we're getting McDonalds on Friday, or if we should rather stick to the leftovers in the fridge.

Here is a small snippit of what the excel document used to look like

There are a few issues though...

• You have to download your bank statements manually. We share a single bank account for expenses and only one of us can receive the In App Authentication request to log in. So only one of us has access to the statements.
• You can't download the statements from the Investec Mobile App, so you need to use a laptop.
• Every now and then we create a copy of the Excel document or save it in a different location. You would think two smart people could keep track of a single document on a shared drive...
• It's still a very manual process you need to dedicate time for.
• It's hard to keep track of your historical trends and you need to flip through Excel sheets
• I am a fan of Vault22 (formerly 22Seven) but it never really did what I wanted. When you go to Checkers you might buy food for yourself and dog food. They aren't both "groceries". One is "pets"
• It's boring and I love coding.

This is where budgetspeech comes in.

I bank with Investec and they support Open Banking, and in South Africa they have a similar set of api's based on the same standard called Programmable Banking

I decided to have fun, over engineer and play around while automating my Excel version of BudgetSpeech.
Read along the next couple of episodes as I discuss what and how I built budgetspeech.

In the video below I used Investec's sandbox environment and credentials. You're welcome to play around with it or just create a Mock Account - no bank account required 😉

One of the lesser known but my favorite features of Enums are Flags

Enums are usually used to indicate a single option, like a day of the week, your favorite colour, pizza size... We all get it, we've all used it, but how often have you seen an array of Enums being passed around in your code?
There was probably a good reason for it if you have. Maybe an array of features, an array of preferred contact methods, supported payment methods? This is what's really cool about Flags, You can capture a selection of enums in a single value :satisfied:

Here is the code in my Github repo that you can check out.

Lets create an enum to store a list of client preferences.

[Flags]
public enum ClientPreferences
{
    None = 0,
    DarkMode = 1,
    LargeText = 2,
    AutoComplete = 4,
    AIAssist = 8,
    AutoOrder = 16
}

Things to note is that I added the [Flags] attribute to the enum, and I set the values to powers of 2 and a default None = 0 enum. This way I can combine the enum values to create a single value that represents a combination of preferences.

Lets create a variable containing some of our preferences and print them out.

var preferences = ClientPreferences.LargeText | ClientPreferences.AutoComplete | ClientPreferences.AutoOrder;
Console.WriteLine($"Preferences String value: {preferences}");
Console.WriteLine($"Preferences Integer value: {(int)preferences}");

Because we selected LargeText, AutoComplete and AutoOrder, the output will be:

// Preferences String value: LargeText, AutoComplete, AutoOrder
// Preferences Integer value: 22

The Integer value is 22 because we added the values of the selected preferences together. This is great because there is no other combination of preferences that will add up to 14!

Using the HasFlag Function, we can check if a preference is selected in a combination of preferences.
Lets print out our preferences to see the HasFlag values.

Console.WriteLine($"Preferences HasFlag:None: {preferences.HasFlag(ClientPreferences.None)}");
Console.WriteLine($"Preferences HasFlag:DarkMode: {preferences.HasFlag(ClientPreferences.DarkMode)}");
Console.WriteLine($"Preferences HasFlag:LargeText: {preferences.HasFlag(ClientPreferences.LargeText)}");
Console.WriteLine($"Preferences HasFlag:AutoComplete: {preferences.HasFlag(ClientPreferences.AutoComplete)}");
Console.WriteLine($"Preferences HasFlag:AIAssist: {preferences.HasFlag(ClientPreferences.AIAssist)}");
Console.WriteLine($"Preferences HasFlag:AutoOrder: {preferences.HasFlag(ClientPreferences.AutoOrder)}");

The output will be:

// Preferences HasFlag:None: True
// Preferences HasFlag:DarkMode: False
// Preferences HasFlag:LargeText: True
// Preferences HasFlag:AutoComplete: True
// Preferences HasFlag:AIAssist: False
// Preferences HasFlag:AutoOrder: True

You'll notice the None enum value is also printed out. This is because the None enum value is 0, and 0 is included in all combinations of preferences. If you don't want a None enum option, you can ommit it and start your index at 1.

"But Kyle, I want to get an array of preferences, not a single value! Please Help!"

You can still get an array of enum values if you want to.

var selectedPreferences =
    System.Enum.GetValues(typeof(ClientPreferences))
    .Cast<ClientPreferences>()
    .Where(p => preferences.HasFlag(p));

And printing out the array, the output will be:

// Preferences in Array: None
// Preferences in Array: LargeText
// Preferences in Array: AutoComplete
// Preferences in Array: AutoOrder

A while ago we had the unfortunate event of breaking prod 😮
We made some small changes to our .net api, all tests passed, everything was good and the world slept peacefully that night, until we saw the service started going down seemingly at random! Turns out it wasn't random at all, it was a pesky async void which we missed changing to an async Task and it caused the entire service to come crumbling down.

Most of us know that when you want to change a method from sync to async, you change the calls to an async Task, it's pretty simple and straight forward, but we forgot to change one of the signatures from void DoSomething() to async Task DoSomething() and left it as async void DoSomething()

"But Kyle, surely in an api the controller will just rethrow the error, right?" - Yes and no!
The problem is in the way that Tasks and voids propagate their exceptions, and the way we didn't await our call.
When an exception is thrown in an async Task, you can await the Task and the exception is captured in the Task's context, even if you don't await the task and it's "fire and forget", the exception is still captured in an anonymous Task's context.
With async void, there is no return type, it's always "fire and forget" and there is no place to capture the exception.
In short it causes an exception in the ThreadPool which causes the application to crash

Let's look at some examples in my github repo to explain some behaviour.

I have a controller with 3 methods to demonstrate the different scenarios

[Route("[controller]/[action]")]
[ApiController]
public class DemoController : ControllerBase
{
    private readonly IDemoService demoService;
    private static readonly string[] demoValues = new[]
    {
        "A", "B", "C"
    };

    public DemoController(IDemoService demoService)
    {
        this.demoService = demoService;
    }

    [HttpGet(Name = "GetTask")]
    public async Task<IEnumerable<string>> GetTask()
    {
        // fire and forget
        // no await so exception will be caught in TaskScheduler.UnobservedTaskException
        // demoValues will be returned
        demoService.PerformTaskAsync();
        return demoValues;
    }

    [HttpGet(Name = "GetTaskAsync")]
    public async Task<IEnumerable<string>> GetAsyncTask()
    {
        // awaits demoService.PerformTaskAsync
        // exception will be thrown and handled in ExceptionMiddleware
        // demoValues will not be returned
        await demoService.PerformTaskAsync();
        return demoValues;
    }

    [HttpGet(Name = "GetVoidAsync")]
    public async Task<IEnumerable<string>> GetAsyncVoid()
    {
        // fire and forget
        // no await so exception will be logged in AppDomain.CurrentDomain.UnhandledException and crash
        // demoValues will be returned
        demoService.PerformVoidAsync();
        return demoValues;
    }
}

I have custom middleware to handle exceptions and do some fancy stuff

public class ExceptionMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<ExceptionMiddleware> _logger;

    public ExceptionMiddleware(RequestDelegate next, ILogger<ExceptionMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext httpContext)
    {
        try
        {
            await _next(httpContext);
        }
        catch (Exception exception)
        {
            // log the error
            _logger.LogError(exception, "error during executing {Context}", httpContext.Request.Path.Value);
            
            var response = httpContext.Response;
            response.ContentType = "application/json";

            //do some fancy error handling
            response.StatusCode = (int)HttpStatusCode.InternalServerError;
            var message = System.Text.Json.JsonSerializer.Serialize($"Whoops, something went wrong! -  {exception.Message}");
            await response.WriteAsync(message);
        }
    }
}

I have some extra event handlers to demonstrate the fire and forget exception behaviour

TaskScheduler.UnobservedTaskException += (sender, e) =>
{
    Console.WriteLine($"*** UnhandledException in TaskScheduler! - {e.Exception}");
};

AppDomain.CurrentDomain.UnhandledException += (sender, e) =>
{
    Console.WriteLine($"*** UnhandledException in AppDomain! - {e.ExceptionObject}");
};

And I have a demo service that will throw some errors in async calls

public class DemoService : IDemoService
{
    public async Task PerformTaskAsync()
    {
        await Task.Delay(1000);
        throw new NotImplementedException(nameof(PerformTaskAsync));
    }

    public async void PerformVoidAsync()
    {
        await Task.Delay(1000);
        throw new NotImplementedException(nameof(PerformVoidAsync));
    }
}

Awaiting async Task - Caught in middleware​

When you await a Task and an exception is thrown, the exception will be stored on the Task's context and the calling code will know how to handle it.

[HttpGet(Name = "GetTaskAsync")]
public async Task<IEnumerable<string>> GetAsyncTask()
{
    // awaits demoService.PerformTaskAsync
    // exception will be thrown and handled in ExceptionMiddleware
    // demoValues will not be returned
    await demoService.PerformTaskAsync();
    return demoValues;
}

In this case of calling the GetTaskAsync endpoint the middleware caught the error and you can see the custom error message "Whoops, something went wrong!" in the result.
This is great and I guess in 99% of cases what you want.

Fire-and-forget async Task - Caught in TaskScheduler.UnobservedTaskException​

When you don't await a Task and an exception is thrown, the exception is handled by the TaskScheduler.UnobservedTaskException

This event provides a mechanism to prevent exception escalation policy (which, by default, terminates the process) from triggering.

This is great, so out of the box if a Task throws an exception and we didn't await it, it won't crash our process and we have the ability to log or react on it! One thing to remember is that the Task has to be collected by the Garbage Collector before the event is raised.

[HttpGet(Name = "GetTask")]
public async Task<IEnumerable<string>> GetTask()
{
    // fire and forget
    // no await so exception will be caught in TaskScheduler.UnobservedTaskException
    // demoValues will be returned
    demoService.PerformTaskAsync();
    return demoValues;
}

When calling the GetTask endpoint, the demoValues get returned by the controller as expected.

But in the console output we could see the log from the TaskScheduler.UnobservedTaskException handler.
Without the UnobservedTaskException handler we would never have known about the exception in the Task.

Fire-and-forget async void - Raised in AppDomain.UnhandledException and crashes​

Now to the problem we had...

[HttpGet(Name = "GetVoidAsync")]
public async Task<IEnumerable<string>> GetAsyncVoid()
{
    // fire and forget
    // no await so exception will be logged in AppDomain.CurrentDomain.UnhandledException and crash
    // demoValues will be returned
    demoService.PerformVoidAsync();
    return demoValues;
}

When making a call to the GetAsyncVoid endpoint it returns the demoValues correctly which is great.

The demoService.PerformVoidAsync was an async void and as explained above, when an exception was thrown, there was nowhere for the exception to go, so it went to hell and took the service with it!

In the AppDomain.UnhandledException handler in my demo I was able to log the exception, but by this time it's too late and the service will inevitably crash.

Here you can see the output from the console window and the exception I logged, along with process exiting at the end.

Key take aways​

• Never use async void - use async Task.
• If you want to fire and forget a Task, use TaskScheduler.UnobservedTaskException handler so that you can monitor unhandled exceptions in your Tasks.
• Never use async void.
• Never use async void.

90% of blogs I read start with something about unit testing, so to not dissapoint anyone I'm making my first blog post about unit testing 😄

I'm a fan of unit testing code for various reasons, mostly because I've felt the pain when there were none! So I want to chat about a pattern I've been using for the better part of a decade but only found out today that it's called the Test Spy Pattern.

The Test Spy is designed to act as an observation point by recording the method calls made to it by the SUT as it is exercised. During the result verification phase, the test compares the actual values passed to the Test Spy by the SUT with the values expected by the test.

Okay I don't think my implemntation is exactly the classic Test Spy pattern, but close enough!

I use functions or actions to verify that method was called correctly and I can easily inspect or set the return value in each test that sets up the function or action.

The reason I use this pattern is because sometimes my framework of choice FakeItEasy, is not so easy 😒 So I create my own implementation of the Interface or Class, which I can use across my project and makes mocking and asserting much easier.

So here are 2 examples where I often end up using the Test Spy Pattern. You can see my demo implementation in Github

• Mocking HttpClient calls.
• Verifying that a call to the ILogger has been made

Mocking HttpClient Calls​

FakeItEasy can't directly fake an HttpClient, the required methods aren't virtual or abstract so they recommend pretty much the same approach as I'm using, by making use of the HttpMessageHandler but they have to do a bit of extra work by calculating the call based on the return type and method name.

If I'm going to do extra magic, I'm going to do it in a way that's easier for me!
Here is my implementation of spying the HttpMessageHandler used by the HttpClient and how I can verify calls being made and mock values being returned.

public class SpyHttpMessageHandler : HttpMessageHandler
{
    internal Func<HttpRequestMessage, HttpResponseMessage> _sendAsync = null;

    protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
        if (_sendAsync == null)
            throw new NotImplementedException(nameof(_sendAsync));
        return Task.FromResult(_sendAsync(request));
    }
}

I have a function called _sendAsync which I can use to verify the request being made and I get to mock the HttpResponseMessage. This makes it really easy to mock different response types, and models.

And the way we use it in our unit test:

[Fact(DisplayName = "When getting WorldTimeByIP and the correct value is returned")]
public async Task GetWorldTime()
{
    //setup
    var response = new WorldTime() { datetime = DateTime.Now, client_ip = "mockClientIp" };
    var responseMessage = new HttpResponseMessage();
    responseMessage.Content = new StringContent(JsonConvert.SerializeObject(response));
    responseMessage.StatusCode = HttpStatusCode.OK;

    messageHandler._sendAsync = (request) =>
    {
        //assert request properties
        Assert.Equal(HttpMethod.Get, request.Method);
        Assert.Equal("http://worldtimeapi.org/api/ip", request.RequestUri.AbsoluteUri);
        
        //return responseMessage
        return responseMessage;
    };

    //act
    var worldTime = await sut.GetWorldTimeFromIP();

    //assert
    Assert.Equal(response.datetime, worldTime.datetime);
    Assert.Equal(response.client_ip, worldTime.client_ip);
}

In this example my DemoClient takes in an HttpClientFactory which I use to create an instance of my HttpClient.
The HttpClient takes in my SpyHttpMessageHandler which I use for mocking and asserting.
Some of the benefits here are that it's really easy to assert the Request being made. I can assert the request.Method, I can assert the URL, the headers, the body, etc.
I also get to specify the HttpResponseMessage just by serializing the model I'd like to return.

Verifying that a call to the ILogger has been made​

The FakeItEasy approach to faking calls to the ILogger isn't pretty and it's hard to verify that you're logging the correct data. The internet is full of examples of how you can do it and all of them is a little bit different. The reason I went with my Test Spy Pattern is that verifying a log message should be one of the simplist things in the world, and surprisingly it wasn't. So I decided to simplify it for my unit testing.

Here is my implementation of spying the ILogger and how I can verify that the correct calls are being made.

public class SpyLogger<T> : ILogger<T>
{
    public IDisposable BeginScope<TState>(TState state)
    {
        return A.Fake<IDisposable>();
    }

    public bool IsEnabled(LogLevel logLevel)
    {
        throw new NotImplementedException();
    }

    internal Action<LogLevel, EventId, object, Exception?> _logInvoked;

    public void Log<TState>(LogLevel logLevel, EventId eventId, TState state, Exception? exception, Func<TState, Exception?, string> formatter)
    {
        if (_logInvoked == null)
            throw new NotImplementedException(nameof(_logInvoked));

        _logInvoked(logLevel, eventId, state, exception);
    }
}

I have an action called _logInvoked which I can use to verify that the logger was called correctly. It's easy to verify the LogLevel, the message or exception which are all important to me.

And the way we use it in our unit test:

[Fact(DisplayName = "When getting WorldTimeByIP and a failed status code is returned")]
public async Task GetWorldTime_fail()
{
    //setup
    var response = "mock response";
    var responseMessage = new HttpResponseMessage();
    responseMessage.Content = new StringContent(response);
    responseMessage.StatusCode = HttpStatusCode.Conflict;

    messageHandler._sendAsync = (request) =>
    {
        //assert request properties
        Assert.Equal(HttpMethod.Get, request.Method);
        Assert.Equal("http://worldtimeapi.org/api/ip", request.RequestUri.AbsoluteUri);

        //return responseMessage
        return responseMessage;
    };

    var logged = false;
    logger._logInvoked = (logLevel, eventId, state, exception) =>
    {
        logged = true;
        Assert.Equal($"Failed to get WorldTime from IP. {responseMessage.StatusCode}: {response}", state.ToString());
    };

    //act
    var worldTime = await sut.GetWorldTimeFromIP();

    //assert
    Assert.Null(worldTime);
    Assert.True(logged);
}

In this implementation I set the _logInvoked action that will be called in my SpyLogger.
I get to look at and assert the actual values being passed to my spy logger and I find it easier to verify the values compared to other frameworks due to the simplistic nature of the Spy Test Pattern.

Welcome to my blog! I'm Kyle, a Software Engineer who loves writing code, sharing what I learn and reading blogs. I often have a million tabs open from reading a blog and deep diving in to the author's content. It's part of what I love about software engineers and our sharing culture.

Thanks for stopping by! Hope you find something useful here 🚀