Permanent caching? about featuremanagement-dotnet HOT 18 CLOSED

Had very similar issue. IConfiguration value was updating as expected, but IFeatureManager permanently returned value that was set on app start.

Turns out, it was caused by services.AddApplicationInsightsKubernetesEnricher();. I'm running locally using docker compose, but plan to migrate to Kubernetes. Very weird side effect.

from featuremanagement-dotnet.

Are you calling UseAzureAppConfiguration as mentioned in this document to set up dynamic updates from Azure App Configuration? https://docs.microsoft.com/en-us/azure/azure-app-configuration/enable-dynamic-configuration-aspnet-core?tabs=core2x#reload-data-from-app-configuration

from featuremanagement-dotnet.

I'm experiencing the same problem, also using Service Fabric to host the application. I can only get the flag to have the updated value if I restart the application in Service Fabric. I'm also using v 2.0.0 of the FeatureManagement packages and v 3.0.2 of AzureAppConfiguration. My code does call UseAzureAppConfiguration as indicated above.

from featuremanagement-dotnet.

For further context, my application is a Hosted Service so there are no HTTP requests coming in. I see that Azure App Configuration provides a refresher that can be used in such cases - does something similar exist for feature flags?

In the meantime I think I'm going to have to convert my actual feature flag into a configuration option that is used as a feature flag.

from featuremanagement-dotnet.

I'm about to try to repro this, but one thing I can point out from the initial issue description is that after making the request after waiting 30 seconds it is expected that the feature flag wouldn't have changed. That's because that request triggers the application to check for any updates from Azure App Configuration. So there would have to be one more request to see the changes.

from featuremanagement-dotnet.

I just ran the FeatureFlagDemo app that's included and pointed to the v2.0.0 version of the libraries. It is behaving as expected. Can you take a look at my previous comment and see if it helps?

from featuremanagement-dotnet.

I was lacking the UseAzureAppConfiguration method but adding it didn't resolve the problem. (I sure was excited for a little while though).

@jimmyca15 I'm not sure why I'd need another request to see the changes. I'll explain a bit more:

If I change the feature flag in Feature Management on Azure, then on the next request to my SF app, I expect the _featureManagerSnapshot to check to see if the cache has expired (when the flag setting is being queried by my app) and then get the update from AppConfig if the cache time has indeed expired. I've done a lot of testing with many other requests with the SF session still running. It doesn't matter how long I wait (even the next day) or how many times I make the same request, the flag doesn't update. Restart SF and it gets the correct value straight away.

Maybe it's a SF problem.

from featuremanagement-dotnet.

@ledpup

Service fabric shouldn't be a factor. If you are running an ASP.NET Core application the hosting platform should be irrelevant. I was unable to repro this with the example FeatureFlagDemo app, but if you are able to provide a minimal repro ASP.NET Core app, I could make sure everything is wired up correctly or perhaps be able to repro it.

@evelynnkaplan

The refresher that you mentioned is also able to refresh feature flags.

from featuremanagement-dotnet.

Hi @jimmyca15, I've stripped out as much as I can for my SF-based implementation of feature flags and put it into a repo. It's at https://github.com/ledpup/ff-demo.

ProgramController.cs gets the FF from AppConfig.
The endpoint is set in appsettings.Development.json (replaced with junk).
"app.UseAzureAppConfiguration();" and "services.AddFeatureManagement();" is in Startup.cs
WebApi.cs does the connection

Thanks so much for your time.

from featuremanagement-dotnet.

Hi @jimmyca15, just thought I'd try bumping on this issue. I haven't found a solution to the problem.

from featuremanagement-dotnet.

Hello @ledpup

I took a look at your repro. I can see that it is stripped down, but it is still intertwined with Service Fabric so I haven't been able to find time to get it set up and that's why I haven't been able to get back yet.

That being said after looking at the code everything looks good, and now I do suspect that somehow Service Fabric is playing a part in this. There are two things I would test.

1. Use IFeatureManager instead of IFeatureManagerSnapshot
2. Check if Service Fabric is disposing services in the service collection.

Number 1 is easy, number 2 requires a bit of playing around to see if Service Fabric is doing something unexpected there. The feature management system relies on a change token, which is disposable, to pick up configuration changes. If service fabric is somehow disposing things then this problem could occur. If I could get the app running on service fabric I would test this by adding my own custom simple class that implements IDisposable to the applications services, get it in a controller and log if it ever gets disposed.

If this could repro without the involvement of Service Fabric then it would be much easier to pin down.

from featuremanagement-dotnet.

Hi @jimmyca15 ,

I tried test 1. It didn't work with IFeatureManager either.
I tried test 2 by adding a basic class that can IDisposable to the DI container. I tried as a singleton and a transient and put a breakpoint on dispose. Singleton stayed alive between requests. Transient disposed on each request. It appears to function as I'd expect.

I committed them to https://github.com/ledpup/ff-demo if you want to review.

from featuremanagement-dotnet.

I'm seeing the same permanent caching issue. Here's a pared down example that I can reproduce it with: https://github.com/dmacdnld/feature-flags-test/.

Never mind! Moving up the call to UseAzureAppConfiguration fixed the issue.

from featuremanagement-dotnet.

I had the same issue where Feature Manager would only return the features defined when starting the app. Any subsequet calls would not get the latest enabled features and would return the original features.

I had to add a singleton of the Configuration in program.cs in order to get the Feature Manager to work.

                webBuilder.ConfigureServices((hostingContext, services) =>
                {
                    services.AddSingleton(hostingContext.Configuration);
                });

My startup.cs looks like this: public Startup(IConfiguration configuration)
{
Configuration = configuration;
}`

@jimmyca15 Do you have any idea why I needed to inject the singleton of the Configuration? I didn't see this in the demo.

from featuremanagement-dotnet.

I had the same issue where Feature Manager would only return the features defined when starting the app. Any subsequet calls would not get the latest enabled features and would return the original features.

I had to add a singleton of the Configuration in program.cs in order to get the Feature Manager to work.

                webBuilder.ConfigureServices((hostingContext, services) =>
                {
                    services.AddSingleton(hostingContext.Configuration);
                });

My startup.cs looks like this: public Startup(IConfiguration configuration)
{
Configuration = configuration;
}`

@jimmyca15 Do you have any idea why I needed to inject the singleton of the Configuration? I didn't see this in the demo.

It's difficult without a simple repro application. It could be possibility that the application code is doing something with a separate configuration provider than the feature manager is seeing.

from featuremanagement-dotnet.

Had very similar issue. IConfiguration value was updating as expected, but IFeatureManager permanently returned value that was set on app start.

Turns out, it was caused by services.AddApplicationInsightsKubernetesEnricher();. I'm running locally using docker compose, but plan to migrate to Kubernetes. Very weird side effect.

Removing this fixed it for me too!! Crazy!

from featuremanagement-dotnet.

@kev24uk

There was an issue with the AddApplicationInsightsKubernetesEnricher method that broke configuration updates at runtime. An issue was filed for it, and it looks like it should be fixed with version 2.0.2.

Details here: microsoft/ApplicationInsights-Kubernetes#236

from featuremanagement-dotnet.

Issue hasn't had any updates. Please feel free to ping if there's still any concerns.

from featuremanagement-dotnet.