Background started task does not finish/gets terminated after the first encountered await

Question

In an ASP.NET application, I have an action which when hit, starts a new background task in the following way:

Task.Factory.StartNew(async () => await somethingWithCpuAndIo(input), CancellationToken.None, TaskCreationOptions.DenyChildAttach | TaskCreationOptions.LongRunning, TaskScheduler.FromCurrentSynchronizationContext());

I'm not awaiting it, I just want it to start, and continuing doing its work in the background. Immediately after that, I return a response to the client.

For some reason though, after the initial thread executing the background work hits an await that awaits the completion of a method, when debugging, I successfully resolve the method, but upon returning, execution just stops and does not continue below that point.

Interestingly, if I fully await this task (using double await), everything works as expected.

Is this due to the SynchronizationContext? The moment I return a response, the synchronizationContext is disposed/removed? (The SynchronizationContext is being used inside the method)

If it is due to that, where exactly does the issue happen?

A) When the Scheduler attempts to assign the work on the given synchronizationContext, it will already be disposed, so nothing will be provided

B) Somewhere down the lines in the method executing, when I return a response to the client, the synchronizationContext is lost, regardless of anything else.

C) Something else entirely?

If it's A), I should be able to fix this by simply doing Thread.Sleep() between scheduling the work and returning a response. (Tried that, it didn't work.)

If it's B) I have no idea how I can resolve this. Help will be appreciated.

Answer 1

As Gabriel Luci has pointed out, it is due the the first awaited incomplete Task returning immediately, but there's a wider point to be made about Task.Factory.StartNew.

Task.Factory.StartNew should not be used with async code, and neither should TaskCreationOptions.LongRunning. TaskCreationOptions.LongRunning should be used for scheduling long running CPU-bound work. With an async method, it may be logically long running, but Task.Factory.StartNew is about starting synchronous work, the synchronous part of an async method is the bit before the first await, this is usually very short.

Here is the guidance from David Fowler (Partner Software Architect at Microsoft on the ASP.NET team) on the matter: https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/blob/86b502e88c752e42f68229afb9f1ac58b9d1fef7/AsyncGuidance.md#avoid-using-taskrun-for-long-running-work-that-blocks-the-thread

See the 3rd bulb:

Don't use TaskCreationOptions.LongRunning with async code as this will create a new thread which will be destroyed after first await.

Answer 2

Your comments made you intentions a little clearer. What I think you want to do is:

1. Start the task and don't wait for it. Return a response to the client before the background task completes.
2. Make sure that the somethingWithCpuAndIo method has access to the request context.

But,

1. A different thread won't be in the same context, and
2. As soon as the first await is hit, a Task is returned, which also means that Task.Factory.StartNew returns and execution of the calling method continues. That means that the response is returned to the client. When the request completes, the context is disposed.

So you can't really do both things you want. There are a couple of ways to work around this:

First, you might be able to not start it on a different thread at all. This depends on when somethingWithCpuAndIo needs access to the context. If it only needs the context before the first await, then you can do something like this:

public IActionResult MyAction(input) {
    somethingWithCpuAndIo(input); //no await
}

private async Task somethingWithCpuAndIo(SomeThing input) {

    // You can read from the request context here

    await SomeIoRequest().ConfigureAwait(false);

    // Everything after here will run on a ThreadPool thread with no access
    // to the request context.
}

Every asynchronous method starts running synchronously. The magic happens when await is given an incomplete Task. So in this example, somethingWithCpuAndIo will start executing on the same thread, in the request context. When it hits the await, a Task is returned to MyAction, but it is not awaited, so MyAction completes executing and a response gets sent to the client before SomeIoRequest() has completed. But ConfigureAwait(false) tells it that we don't need to resume execution in the same context, so somethingWithCpuAndIo resume execution on a ThreadPool thread.

But that will only help you if you don't need the context after the first await in somethingWithCpuAndIo.

Your best option is to still execute on a different thread, but pass the values you need from the context into somethingWithCpuAndIo.

But also, use Task.Run instead of Task.Factory.StartNew for reasons described in detail here.

Update: This can very likely cause unpredictable results, but you can also try passing a reference to HttpContext.Current to the thread and setting HttpContext.Current in the new thread, like this:

var ctx = HttpContext.Current;
Task.Run(async () => {
    HttpContext.Current = ctx;
    await SomeIoRequest();
});

However, it all depends on how you are using the context. HttpContext itself doesn't implement IDiposable, so it, itself, can't be disposed. And the garbage collector won't get rid of it as long as you're holding a reference to it. But the context isn't designed to live longer than the request. So after the response is returned to the client, there may be many parts of the context that are disposed or otherwise unavailable. Test it out an see what explodes. But even if nothing explodes right now, you (or someone else) might come back to that code later, try to use something else in the context and get really confused when it blows up. It could make for some difficult-to-debug scenarios.