An exception should be thrown if a configured feature filter has not been registered. about featuremanagement-dotnet HOT 6 CLOSED

The initial design is that exceptions are not thrown if feature filters are specified for a feature and not registered in the application. We have multiple users already using this default functionality. I believe the best approach would be to keep the default behavior and to instead expose the option such that a developer can trigger the exceptions to throw.

from featuremanagement-dotnet.

@zhenlan you raise a good point. Promoting that as default doesn't lead to best production practices. We should encourage deterministic feature configuration. Going forward switching the default behavior to throw for unregistered filters sounds like a better option. I think it is best for us to take this change now.

from featuremanagement-dotnet.

The existing behavior is important for the users only because the change is a breaking one and for no other reason. The deterministic feature configuration (best production practice) is more important than not making a breaking change. especially at the current state where FeatureManagement is still in preview.

from featuremanagement-dotnet.

@zhenlan @MSGaryWang any preferences either way?

from featuremanagement-dotnet.

@jimmyca15 what you are proposing makes totally sense, regarding that multiple users already using the default functionality. I will wait for @zhenlan and @MSGaryWang comments before making any changes.

from featuremanagement-dotnet.

The initial design is that exceptions are not thrown if feature filters are specified for a feature and not registered in the application.

Is this to allow users to add new filters to existing feature flags in App Configuration before updating/redeploying the application? This doesn't sound like a good practice we would recommend for users to do in production.

I'm not sure I like the silent failure here. I need to understand better why the existing behavior is important for some users (aside from it's a breaking change). If that's indeed the case, I think we should still throw by default and provide an option to suppress it.

from featuremanagement-dotnet.