AsyncLocal loses state when ServiceProviderScope is Disposed

[danstur]

It seems like AsyncLocal does not keep its state until the scope created for executing a controller is finished disposed. This means that a value set in AsyncLocal during a controller call is not available when the injected dependencies are disposed - instead the value is always null.

Not sure if this is intended or not, but it'd be nice to document this behavior somewhere and maybe provide a work around. Using AsyncLocal to store some information that's required during a call is not unheard of and if you store resources that have to be cleaned up in it, this is rather cumbersome currently.

Example. Put the following into the default asp.net core Web API project template for netcoreapp2.1 and register TestRepo as a transient dependency. When executing GET api/values we get an exception during TestRepo::Dispose because the asynclocal value is null instead of 5.

[Route("api/[controller]")]
public class ValuesController : Controller
{
    private readonly TestRepo _testRepo;

    public ValuesController(TestRepo testRepo)
    {
        _testRepo = testRepo;
    }

    [HttpGet()]
    public async Task<IActionResult> Get()
    {
        _testRepo.SetValue(5);
        await Task.Delay(100);
        var val = _testRepo.GetValue(); 
        // val here has correctly 5.
        return Ok();
    }
}

public class TestRepo : IDisposable
{
    private static readonly AsyncLocal<int?> _asyncLocal = new AsyncLocal<int?>();

    public int? GetValue()
    {
        return _asyncLocal.Value;
    }

    public void SetValue(int x)
    {
        _asyncLocal.Value = x;
    }

    public void Foo()
    {
        SetValue(5);
    }

    public void Dispose()
    {
        if (GetValue() == null)
        {
            throw new InvalidOperationException("GetValue() should be 5 here :(");
        }
    }
}

Current behavior: Dispose throws a InvalidOperationException.
Expected behavior: GetValue() returns 5 inside TestRepo::Dispose

[Tratcher]

There's no relation between DI, scopes, and AsyncLocal. AsyncLocal is all about threading and call stacks.

From this example, AsyncLocal propagates down a call stack but not up it.
https://dzone.com/articles/the-dangers-of-threadlocal

[danstur]

"AsyncLocal is all about threading and call stacks."
I'd say AsyncLocal is mostly all about execution contexts, not so much about call stacks or threads. And the problem here is that when the framework disposes its scope it does so while the relevant execution context is not set.
This might just be by design, but it seems weird to do so considering that the framework goes through a lot of effort to make sure that the execution context is kept during the controller execution - why execute only the Dispose methods in a different execution context?

"From this example, AsyncLocal propagates down a call stack but not up it."
I don't see where it says that at all and it's also clearly not true. Neither in old full Frameworks with synchronization contexts and definitely not in .net core. Just try the following example:

        private static readonly AsyncLocal<int?> _asyncLocal = new AsyncLocal<int?>();

        static void Main(string[] args)
        {
            SetValue();
            Console.WriteLine(_asyncLocal.Value); // this prints 5.
        }

        private static void SetValue()
        {
            _asyncLocal.Value = 5;
        }

[Tratcher]

Ah, that example was using .ConfigureAwait(false); so that makes sense.

https://github.com/aspnet/Hosting/blob/b3625b8173b19935e22b4fe5ac0ea64edd934bd4/src/Microsoft.AspNetCore.Hosting/Internal/RequestServicesFeature.cs#L33
Called from here:
https://github.com/aspnet/KestrelHttpServer/blob/61e16e2b3108b6fc4dc9f7e690dd1e55a0cfe3b5/src/Kestrel.Core/Internal/Http/HttpProtocol.cs#L617

I don't see specifically where it drops the thread context.

[davidfowl]

I don't see where it says that at all and it's also clearly not true. Neither in old full Frameworks with synchronization contexts and definitely not in .net core. Just try the following example:

It is true. Here's an example:

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.AspNetCore;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.Logging;

namespace asyncflow
{
    public class Program
    {
        private static readonly AsyncLocal<int?> _asyncLocal = new AsyncLocal<int?>();

        static void Main(string[] args)
        {
            Thing1().GetAwaiter().GetResult();
        }

        static async Task Thing1()
        {
            await Thing2();
            Console.WriteLine(_asyncLocal.Value); // this prints null
        }

        static async Task Thing2()
        {
            SetValue();
            Console.WriteLine(_asyncLocal.Value); // this prints 5.
        }

        private static void SetValue()
        {
            _asyncLocal.Value = 5;
        }
    }
}

MVC action execution isn't a single async flow so setting the value in a controller won't be observable in dispose. The value set in the async local don't bleed out of the context in which it was set.

[Eilon]

@Tratcher / @davidfowl - any further action required on this issue?

[danstur]

Seem to have missed the mail about @davidfowl's comment, hum, sorry for that.

Interesting, I'll have to look into what exactly constitutes a single async flow, my understanding clearly has some white spots, since I'd expect @davidfowl's sample to print 5 twice.

Closing.

[thienly]

I don't see where it says that at all and it's also clearly not true. Neither in old full Frameworks with synchronization contexts and definitely not in .net core. Just try the following example:

It is true. Here's an example:

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.AspNetCore;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.Logging;

namespace asyncflow
{
    public class Program
    {
        private static readonly AsyncLocal<int?> _asyncLocal = new AsyncLocal<int?>();

        static void Main(string[] args)
        {
            Thing1().GetAwaiter().GetResult();
        }

        static async Task Thing1()
        {
            await Thing2();
            Console.WriteLine(_asyncLocal.Value); // this prints null
        }

        static async Task Thing2()
        {
            SetValue();
            Console.WriteLine(_asyncLocal.Value); // this prints 5.
        }

        private static void SetValue()
        {
            _asyncLocal.Value = 5;
        }
    }
}

MVC action execution isn't a single async flow so setting the value in a controller won't be observable in dispose. The value set in the async local don't bleed out of the context in which it was set.

Hi @davidfowl , Hope you don't mind my question.
MVC action execution is not a single async flow? Can you explain more about this?

[EnricoMassone]

Hi @thienly,

in order for you to better understand the example from @davidfowl I suggest you to read the following blog posts from Stephen Cleary:

• read all of this article first
• read at least the paragraph AsyncLocal of this article

If you want to better understand the content of the first article (particularly the meaning of ExecutionContext) I highly recommend you to read this blog post from Stephen Toub .

The key point in David Fowl's code is that the method Thing2 is declared with the async modifier. If you are inside an async method and you set the Value property of an AsyncLocal<T> instance you are basically doing two things (in the article of Stephen Cleary linked above this is called copy on write behavior):

1. a copy of the AsyncLocal<T> instance is done (pay attention it's a shallow copy, not a deep one. This is has some consequences as explained later)
2. the copy done at the previous point is modified using the new value you are setting

From that point on, if you query your AsyncLocal<T> instance you will see the new value that you have set: that's why the call to Console.WriteLine made inside Thing2 prints the value 5. You can think of this behavior in the following manner: each time you enter an async method a fresh new async context is initiated and this context is isolated from its parent async context. This means that ,inside your async method, you can set and query your AsyncLocal<T> having the guarantee that you are not polluting the parent async context because your changes are local to the current async context.

As a best practice you should always store immutable data types inside an AsyncLocal<T>, because of the aforementioned shallow copy issue. Doing you are sure that your async contexts are completely isolated and don't interact each others if you tries to modify the value read from the AsyncLocal<T> instance. So, remember: always use an immutable data type as the type argument for AsyncLocal.

When the async method returns you are back in the parent async context and, from there, you can't see the modifications performed by the child async context. This is the reason why when you call Console.WriteLine in the method Thing1 the null value will be printed.

I'm not sure of what @davidfowl means when he says that

MVC action execution isn't a single async flow

but I guess that this means there are multiple async contexts involved in the handling of an incoming HTTP request.

Assuming my guess is correct and referring to the original code of this issue, you can't expect that a value set on the AsyncLocal<T> of the TestRepo instance from inside an action method will also be available when the Dispose method of TestRepo will be called. The action method body and the Dispose method body are executed inside two different async contexts, so the value set in the first one won't be available in the second one.

Hope this helps !