Using of AzureAppConfigurationRefreshMiddleware breaks durable function orchestration

[ivankaurov]

Code of AzureAppConfigurationRefreshMiddleware includes the following line

await next(context).ConfigureAwait(false);

This line breaks the execution of Durable Orchestrator by leaving it in running state even after the execution is completed succesfully. It means that Microsoft.Azure.AppConfiguration.Functions.Worker package and especially AzureAppConfigurationRefreshExtensions.UseAzureAppConfiguration can't be used with Durable out-of-process Azure functions.

This can refer to the constraint that Orchestrators can't use .ConfigureAwait(false) in there code.

[jimmyca15]

@ivankaurov

It sounds then that our library needs to know if it's running on a platform that doesn't support ConfigureAwait. Up until this point the adopted practice has been always use ConfigureAwait. My initial thinking is that we'll need to figure out a way to detect that our library is running in this environment and have some helper to decide whether to configure await or not.

Thank you for reporting !

@amerjusupovic

[cgillum]

/cc @jviau

[jviau]

I don't believe there is anything for AppConfiguration team to do here. The issue lies entirely on the durable side, we are imposing a constraint on the rest of the functions middleware pipeline - which frankly is not a good design on our end. There is an issue I opened to provide an extensibility point to for durable to avoid the issue: Azure/azure-functions-dotnet-worker#1666

[JonathanNagy]

I came up with a "synchronous" version of the AppConfigurationRefreshMiddleware. It works, but I am reluctant to use it as I don't want to worry about who will maintain it if the AzureAppConfiguration library is updated. I'd be nice if this were fixed, but I can live with having to restart the app function to refresh the configuration. That seems to be the full extent of what UseAzureAppConfiguration() does currently.