UseAzureAppConfiguration and AzureAppConfigurationRefreshMiddleware break context execution

[fjbelizon]

I have detected that if we make use of ‘UseAzureAppConfiguration’, which in turn internally injects the middleware ‘AzureAppConfigurationRefreshMiddleware’, it breaks the execution of the context of the Eternal Orchestration Functions.

I am using Azure Isolated Function in NET 8, using package ‘Microsoft.Azure.AppConfiguration.Functions.Worker’ in version 7.2.0.

The middleware internally performs an ‘ExecutionContext.SuppressFlow()’, which breaks the execution flow of the context: https://learn.microsoft.com/en-us/dotnet/api/system.threading.executioncontext.suppressflow?view=net-8.0

Right now the solution I am applying is to use ‘AddAzureAppConfiguration’ without ‘UseAzureAppConfiguration’. In my orchestrator constructor I inject ‘IConfigurationRefresherProvider’ to use the configuration refresher in the orchestrator activities.

The problem is not described anywhere and should be checked. Thanks in advance.

[amerjusupovic]

Hi @fjbelizon, we got a similar issue about durable functions being broken a while back, but ExecutionContext.SuppressFlow() wasn't mentioned. In the discussion there as well as in the linked issue that's in the Azure Functions repo, it was thought that the problem was not specific to the Azure App Configuration middleware.

One helpful test would be to see if version 6.0.1 of the provider also causes this issue for you, since that was before we added the call to SuppressFlow(). If the issue goes away, I'll need to update that original issue. Thanks!

[fjbelizon]

Hi @amerjusupovic. Ok, I'm going to do the test

[fjbelizon]

@amerjusupovic yes, same problem. Version 6.0.1 also breaks the execution of Eternal Functions.

I attach the code sample for you to test: bug-azure-app-configuration-refresh-middleware.zip. I've put two ‘TODO’ tags for you to comment/uncomment the lines that make the execution work/fail.

I look forward to your review. Thanks in advance.

[sparraguerra]

Any news about this issue? Thanks in advance

[jimmyca15]

@amerjusupovic

Given there was a repro with 6.0.1 do you believe it would be the same issue as here?

[fjbelizon]

Ok, thanks @amerjusupovic 👌

[jimmyca15]

This looks like a dupe of this issue. I don't think ExecutionContext.SuppressFlow has any involvement here. This supported by 6.0.1 reproing as well.

[jimmyca15]

@amerjusupovic if you can confirm this is a dupe of the aforementioned issue we should merge this issue into the existing one which the Functions team mentioned they need to solve on their end.

[amerjusupovic]

Sorry for the confusion in my previous response, yes the repro in 6.0.1 suggests it's the same issue, and that was before the call to SuppressFlow was added. This should be merged with the existing one.

[BrunoCandia]

is there any news about this issue? or any alternative, thanks in advance!!

[ivankaurov]

@BrunoCandia we're using the BackgroundService that is thechnically doing the same stuff

internal sealed class AzureAppConfigRefreshService : BackgroundService
{
    private readonly IEnumerable<IConfigurationRefresher> _refreshers;

    public AzureAppConfigRefreshService(IConfigurationRefresherProvider refresherProvider)
    {
        _refreshers = refresherProvider.Refreshers;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            try
            {
                foreach (var refresher in _refreshers)
                {
                    await refresher.TryRefreshAsync(stoppingToken);
                }

                await Task.Delay(...);
            }
            catch (OperationCanceledException) when (stoppingToken.IsCancellationRequested)
            {
                _logger.LogInformation("AzureAppConfig has been stopped");
                break;
            }
        }
    }
}
// ...
// serviceCollection.AddHostedService<AzureAppConfigRefreshService>();

[ivankaurov]

@amerjusupovic @jimmyca15 are there any news on this issue? We're still using our in-house kludge