Azure-functions-durable-extension: .ConfigureAwait(false) causes infinite `Running` state

[SayusiAndo]

Description

When the activity methods are called with .ConfigureAwait(false), then the status url shows that the process is in Running state, instead of Completed after a while.
I have another example where I'm using DI to inject libraries connecting to database and the result is the same.

Expected behavior

I assume .ConfigureAwait(false) should not cause any functionality change. AFAIK the only case when it shouldn't be used is working with WPF and UI threads (I might be mistaken).

Actual behavior

• generate the default example with VS, modified as it is provided below
• hit the endpoint
• hit the status url
• check the status, which never will be other than Running, instead of Complete after a while

Relevant source code snippets

[FunctionName("Function1")]
        public static async Task<List<string>> RunOrchestrator(
            [OrchestrationTrigger] IDurableOrchestrationContext context)
        {
            var outputs = new List<string>();

            // Replace "hello" with the name of your Durable Activity Function.
            outputs.Add(await context.CallActivityAsync<string>("Function1_Hello", "Tokyo").ConfigureAwait(false));
//            outputs.Add(await context.CallActivityAsync<string>("Function1_Hello", "Seattle"));
//            outputs.Add(await context.CallActivityAsync<string>("Function1_Hello", "London"));

            // returns ["Hello Tokyo!", "Hello Seattle!", "Hello London!"]
            return outputs;
        }

Known workarounds

One should not use .ConfigureAwait(false) when activity methods are called

App Details

• Durable Functions extension version (e.g. v2.0.0-beta3):
• Azure Functions runtime version (2.0):
• Programming language used: C#:

[ConnorMcMahon]

I am about 95% sure that this is expected. In fact, there is already an issue to properly reflect this in our docs. This project is built on the Durable Task framework, which plays around a lot with the .NET Task layer, so setting .ConfigureAwait(false) could easily interfere with that. @cgillum could confirm whether this is expected.

If this is something we want to discourage customers from doing, we could use this issue to track adding it to our analyzer, as well as the docs.

[ConnorMcMahon]

Documentation issue has been merged, so I am removing the docs tag, and putting this issue on our backlog for analyzer work.

[cgillum]

Yes, I can confirm that .ConfigureAwait(false) will almost always break the orchestration task scheduler. It would be great to have the analyzer catch this. :)