Support RequirementType property for feature flags

[avanigupta]

With Microsoft.FeatureManagement 2.6.0-preview release, feature flags now have an additional property called RequirementType that needs to be parsed by the FeatureManagement adapter. See this PR for the new syntax: microsoft/FeatureManagement-Dotnet#221

[Joerio]

This is great and works very well. I do however have some issue with this new property in combination with Azure App Configuration. Is this already supported, and if so, what property do I need to add in that configuration?

I only get it to work at this moment if I add the feature also in mine appsettings.json with the property RequirementType, I can leave the rest of the configuration (filters) in Azure. It would be great if I didn't have to put anything at all in my local appsettings.json.

[avanigupta]

Hi Joeri (@Joerio), thanks for the feedback! Right now, it will only work when you specify RequirementType in your config file. We are working on adding this support in Azure App Configuration too.

[Eskibear]

I have some questions while trying to implement the feature. Probably some clarification required.

• Do we always set property FeatureManagement:<FeatureId>:RequirementType, even if requirement_type is not specified in raw data? If so, I think we can use its default value "Any".
• What if requirement_type has an invalid value? Do we throw an exception or silently fallback to set "Any" (which is not a good idea from my gut feeling)?

[avanigupta]

Config provider is responsible for parsing feature flags stored in AppConfig service and adding them to application configuration. Then the Feature Management library consumes these feature flags through IConfiguration. This means that config provider doesn't need to add default value for RequirementType - it just needs to understand how to parse a feature flag if it contains RequirementType. Even if the value of RequirementType is invalid, config provider shouldn't worry about the semantics of RequirementType and just treat it as a free form string. The FeatureManagement library will handle these cases of missing/invalid RequirementType appropriately.

[Eskibear]

Thank you for the clarification, and it makes a lot sense to me now. Then I think I can simply regard requirement type as a string here in the provider.