An exception should be thrown if a configured feature filter has not been registered.

[jimmyca15]

If a feature is configured to be enabled for a certain feature filter, the feature management pipeline should throw if that feature is being evaluated and the feature filter can not be found. Without this behavior it is very hard to track down the fact that a feature filter has been excluded from being registered. For those who intend for this behavior and depend on an exception not being thrown, this could be configurable via feature management options.

[jimmyca15]

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.

[jimmyca15]

@zhenlan @MSGaryWang any preferences either way?

[codapus-co]

@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.

[zhenlan]

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.

[jimmyca15]

@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.

[codapus-co]

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.