IgnoreMissingFeatureFilters should not be false by default

[Rutix]

Hi,

I was wondering why IgnoreMissingFeatureFilters is by default false? This is super dangerous when you have multiple services and can lead to significant production problems. We have the following situation:

• We use Azure App Configuration Feature Manager to manage the whole load of feature toggles.
• All services connect to that Azure App Configuration
• We have configured in all our services that the feature toggles are refreshed
• In most services we had the following configured: services.AddFeatureManagement();
• Someone on production saw the "Microsoft.TimeWindow" feature filter and thought: "Hey that's handy!" and configured it. This caused all services to fail and throw exceptions which caused production outages.

Apart from that we should have tested this in a development environment, it is my opinion that "forgotten configuration" should never break an application. Especially since this can be a full sneaky mode and be caused by someone else.

I found #13 where this is discussed but I think the perspective of the default isn't discussed very well there.

[jimmyca15]

I was wondering why IgnoreMissingFeatureFilters is by default false?

It is default to false to prevent unintentionally missing feature filter registration. This way when applications are being built-out no misconfiguration goes unnoticed.

The problem you are mentioning is valid, but it does happen because of touching live configuration in production. And as you mentioned that configuration update wasn't verified in any development environment. It's difficult to design for a scenario like that where so many things can go wrong. But, we offer the IgnoreMissingFeatureFilters flag if that is a workflow that is desired.

It was a pros and cons decision and in the end the decision was to make it easier to avoid misconfiguration in development.

[Rutix]

I was wondering why IgnoreMissingFeatureFilters is by default false?

It is default to false to prevent unintentionally missing feature filter registration. This way when applications are being built-out no misconfiguration goes unnoticed.

The problem you are mentioning is valid, but it does happen because of touching live configuration in production. And as you mentioned that configuration update wasn't verified in any development environment. It's difficult to design for a scenario like that where so many things can go wrong. But, we offer the IgnoreMissingFeatureFilters flag if that is a workflow that is desired.

It was a pros and cons decision and in the end the decision was to make it easier to avoid misconfiguration in development.

I understand where you are coming from but you are basically saying that the risk in development trumps the risk in production. I wholeheartedly disagree with that. If you forget in development then you will find out quickly and at worst might have to make a change to fix it for yourself. In production (and especially with a lot of teams and big organizations) someone might decide to use the TimeWindow to roll out on a certain date in production (while it has been tested in development with the feature toggle on true) and that can cause downtime on areas you are not responsible for or know of.

It's basically an argument of debugging/tracking why something doesn't work vs a potential production shutdown because of the defaults. I hope you can agree that the second one is a way bigger risk. So I hope you and your team want to reconsider the default setting of this one.

[zhiyuanliang-ms]

@Rutix After discussion, we still want to remain the default value of IgnoreMissingFeatureFilter as false. But we plan to register the built-in filter like TimeWindow and Targeting filter by default after calling AddFeatureManagement().

[jimmyca15]

@Rutix

We have discussed this issue and have opted not to change the existing behavior. A slight mitigation has been implemented to add the TimeWindow filter by default, thus it will never be missing.

[Rutix]

@jimmyca15 / @zhiyuanliang-ms the mitigation lowers the risk considerably so I can live with that. Thanks for thinking along!