In serverless applications like Azure Functions, managing execution-specific context (like Correlation ID, or a custom CV header) becomes tricky — especially when these values need to be accessed deep inside services that are registered as singletons.

This post walks through a clean, reusable solution for maintaining per-invocation state using AsyncLocal<T>, making it accessible from any service without breaking dependency injection (DI) patterns.

💡 The Problem

Azure Functions typically inject services using the built-in dependency injection container. But in scenarios like:

• Logging telemetry (CV, CorrelationId, TenantId, etc.)
• Accessing user/request context from deep within services
• Sharing state across the call chain (without polluting every method signature)

…you run into problems when your services are singleton, but the context is per function invocation.

You can’t make the context scoped because Azure Functions don't have native support for request-scoped lifetimes.

✅ The Solution: Use AsyncLocal<T> for Scoped-Per-Invocation Behavior

.NET provides AsyncLocal<T>, which flows naturally with asynchronous calls. It works like a thread-local variable, but respects async/await flow — making it ideal for per-invocation context in Azure Functions.

🧱 Step-by-Step Implementation

1️⃣ Define the Context Interface

public interface IExecutionContext
{
    string CV { get; set; }
    string CorrelationId { get; set; }
}

2️⃣ Create the Per-Invocation Context Model

public class DefaultExecutionContext : IExecutionContext
{
    public string CV { get; set; }
    public string CorrelationId { get; set; }
}

3️⃣ Create a Backing Store Using AsyncLocal<T>

public class AsyncLocalContextStore : IExecutionContextStore
{
    private static readonly AsyncLocal<IExecutionContext> store = new();

    public static void Set(IExecutionContext context)
    {
        if (store.Value != null)
        {
            throw new InvalidOperationException("Execution context is already set. Clear it before setting a new one.");
        }

        store.Value = context;
    }

    public static void Clear() => store.Value = null;

    private IExecutionContext Current => store.Value ?? throw new InvalidOperationException("Execution context not set.");

    public string CV { get => Current.CV; set => Current.CV = value; }
    public string CorrelationId { get => Current.CorrelationId; set => Current.CorrelationId = value; }
}

4️⃣ Create the DI-Injectable Context Wrapper

public class ExecutionContext : IExecutionContext
{
    private readonly IExecutionContextStore store;

    public ExecutionContext(IExecutionContextStore store)
    {
        this.store = store;
    }

    public string CV { get => store.CV; set => store.CV = value; }
    public string CorrelationId { get => store.CorrelationId; set =>
}

5️⃣ Register the Services in Your DI Container

builder.Services.AddSingleton<IExecutionContext, ExecutionContext>();
builder.Services.AddSingleton<IExecutionContextStore, AsyncLocalContextStore>();

6️⃣ Set the Context at the Start of Each Function Invocation

public async Task RunAsync(
    [ServiceBusTrigger("queue-name", Connection = "MyServiceBus")] ServiceBusReceivedMessage message)
{
    try
    {
        AsyncLocalContextStore.Set(new DefaultExecutionContext
        {
            CV = "...",
            CorrelationId = "...",
        });

        // do stuff;
    }
    finally
    {
        AsyncLocalContextStore.Clear();
    }
}

7️⃣ Access the Context Anywhere

public class TelemetryLogger
{
    private readonly IExecutionContext context;

    public TelemetryLogger(IExecutionContext context)
    {
        this.context = context;
    }

    public void Log()
    {
        Console.WriteLine($"CV: {context.CV}, CorrelationId: {context.CorrelationId}");
    }
}

Works seamlessly even in singleton services.

🔐 Optional: Safety Check in .Set(...)

The defensive check ensures you don’t accidentally overwrite context mid-execution:

public static void Set(IExecutionContext context)
{
    if (store.Value != null)
    {
        throw new InvalidOperationException("Execution context is already set. Clear it before setting a new one.");
    }
    store.Value = context;
}

🚀 Conclusion

Managing execution context in Azure Functions doesn’t need to be messy or inconsistent. By using AsyncLocal<T> as a backing store, you can safely track execution-specific data like CVs and correlation IDs and make it accessible across your entire service layer — even in singleton components.

This pattern is lightweight, testable, and production-safe. Give it a try the next time you need to thread context through your Azure Function logic!

A new SDK for ServiceBus was released in August 2017 and has resulted in many people to move from WindowsAzure.ServiceBus to Microsoft.Azure.ServiceBus. With the new SDK being .NET Standard 2.0 compatible making it usable cross platform in .NET core applications, here is why you’d want to use .NET core. The new SDK is open source, https://github.com/Azure/azure-service-bus-dotnet, and in general provides cleaner API. I will list the set of changes I faced while migrating to the new SDK.

Brokered Message changed to Message

The object used to represent a message has been changed from BrokeredMessage to Message. There are 2 sets of propertiey collections on message object SystemProperties and UserProperties. Fields like DeadLetterSource, DeliveryCount, EnqueuedSequenceNumber, LockToken, SequenceNumber, are now part of SystemPropertiesand not accessed by message object. Convenience methods like CompleteAsync, AbandonAsync, and DeadLetterAsync were called on BrokeredMessage directly are not available on Message object and functionality can be achieved with the help of ClientEntity.

Client Entity and Message Receiver

The above mentioned convenience methods are now exposed via QueueClient, TopicClient, SubscriptionClient. RenewLockAsyncis not exposed via QueueClient anymore , we don’t have a way of renewing the lock for longer than the MaxAutoRenewDuration duration specified in MessageHandlerOptions Another change in QueueClient is, it does not expose Receive and ReceiveBatchapis. Functionality of recieving a batch of messages from a queue or a dead letter queue can be achieved by using MessageReceiver Which can be also used to call RenewLockAsync deprecated from QueueClient.

Namespace Manager changed to Management Client

The old NamespaceManagerhas been changed to ManagementClient. Most API’s are similar. One big change here was CreateQueueand DeleteQueuehave changed to async implementations of CreateQueueAsyncand DeleteQueueAsync. DeleteQueueAsync now throws MessagingEntityNotFoundException if queue specified does not exist.

Default transport type

The default transport type is AMQP. This was blocked by firewall and I was getting connection exceptions. So I switched to the other option of AMQP over WebSockets which uses port 443. To configure this option we need to append ;TransportType=AmqpWebSockets to the end of the connection string.

Exceptions

While creating a queue if there is a synchronization issue we would get a MessagingException with conflict code 409. In the new SDK this exception propogated by ServiceBusException with conflict sub code 40901. Inactivity is now indicated via an exception ServiceBusCommunicationException, ‘The connection was inactive for more than the allowed 60000 milliseconds and is closed by container’. If there is no action, the connection is automatically closed. However, the next connection will reconnect automatically. This log just details the behavior.
In this SDK exceptions now derive from ServiceBusException class, which has a property isTransient. If an operation throws a transient exception you could retry. If you are using using PUMP and exception is thrown before ProcessMessagesAsync is called, it comes down to handling of that exception in the exception handler. The pump already takes care of retries for you, so you don’t need to worry about that. Its up to you on how you want to log the exceptions. These transient exceptions that can definitely happen and is expected. But it is advised to log them since having a lot of transient exceptions continuously might have to be looked into. If the exceptions are scoped to a small period, then probably it would be related to some service restarts (load-balancing / service upgrades / OS updates etc).

Regarding non-transient exceptions, it is very much a case-by-case basis. You can find more details here

Useful Links

Here are some examples of functionalities which can be helpful when migrating.

1. Documentation
2. Receive Message Using QueueClient (Register a listener when message is sent to queue)
3. Receive Single Message from queue (Using Message Receiver)

Use the above example to recieve a batch of messages or recieve messages from Dead Letter Queue

var deadletterReceiver = new MessageReceiver(namespaceConnectionString, EntityNameHelper.FormatDeadLetterPath(queueName), ReceiveMode.PeekLock);

var messagesBatch = deadletterReciever.ReceiveAsync(int maxMessageCount, TimeSpan operationTimeout);