Feature filter from second configuration source is not respected when the base configuration does not specify a filter
Closed this issue · 1 comments
I have run into something yesterday that cost me quite a bit of time and headache to figure out, and is incorrect behavior in my opinion.
If I specify the following feature flag in my appsettings.json:
"FeatureManagement": {
"Manage_Folders": true
}
And override this value in Azure App Configuration with:
{
"id": "Manage_Folders",
"description": "Enable folder management",
"enabled": true,
"conditions": {
"client_filters": [
{
"name": "Microsoft.Targeting",
"parameters": {
"Audience": {
"Users": [],
"Groups": [],
"DefaultRolloutPercentage": 50
}
}
}
]
}
}
This does not work as expected, as the filter is never evaluated and the feature is turned on for 100% of the requests.
In other situations, the behavior is correct and the filter is evaluated using the values supplied in Azure App Configuration:
- Situation 1: toggle set to false
appsettings.json
"FeatureManagement": {
"Manage_Folders": false
}
Azure App Configuration:
{
"id": "Manage_Folders",
"description": "Enable folder management",
"enabled": true,
"conditions": {
"client_filters": [
{
"name": "Microsoft.Targeting",
"parameters": {
"Audience": {
"Users": [],
"Groups": [],
"DefaultRolloutPercentage": 50
}
}
}
]
}
}
- Situation 2: A filter is also specified in appsettings.json, which is correctly overridden by the values from Azure App Configuration
appsettings.json
"FeatureManagement": {
"Manage_Folders": {
"EnabledFor": [
{
"Name": "Percentage",
"Parameters": {
"Default": "0"
}
}
]
}
}
Azure App Configuration:
{
"id": "Manage_Folders",
"description": "Enable folder management",
"enabled": true,
"conditions": {
"client_filters": [
{
"name": "Microsoft.Targeting",
"parameters": {
"Audience": {
"Users": [],
"Groups": [],
"DefaultRolloutPercentage": 50
}
}
}
]
}
}
Currently I managed to find a workaround for my usecase, but this behavior is incorrect in my opinion.
Hello @robertvandiest
I agree with your sentiment. This concern is also detailed in this previous issue: #74.
I'd like to continue the conversation there if possible.
I would say the issue is a bit tricky here, and I'd like to know if you can provide the scenario that motivates you to do this to help see if it can drive a solution. The issue arises due to how .NET core configuration system works, which is a layer underneath this library.
I will close this issue in hopes that we can continue in the existing issue thread.