Open ivankaurov opened 8 months ago
@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
/cc @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: https://github.com/Azure/azure-functions-dotnet-worker/issues/1666
Code of AzureAppConfigurationRefreshMiddleware includes the following line
This line breaks the execution of Durable Orchestrator by leaving it in
running
state even after the execution is completed succesfully. It means thatMicrosoft.Azure.AppConfiguration.Functions.Worker
package and especiallyAzureAppConfigurationRefreshExtensions.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.