Can't Upgrade to v3.0.0 - "The feature filter '' specified for feature '' was not found.
Closed this issue · 8 comments
Our team implements two custom feature filters: MyContextualFilter & MyFeatureFilter.
As soon as we upgrade from v2.6.1, we receive the following error Microsoft.FeatureManagement.FeatureManagementException: The feature filter 'MyContextual' specified for feature 'TEST-123' was not found. after calling await _featureManager.IsEnabledAsync("TEST-123").
- I thought maybe it was an issue with how the flag was created, so I used another arbitrary name and it resulted in the same error.
- The breakpoint set in both feature filters at the start of
EvaluateAsyncis never hit
This is where the error originates from and it seems like it has to be related to this change, as its the only change on this file since v3.0.0 was released.
Anyone have any ideas? Really scratching our heads here, and we need to upgrade ASAP
ETA: it seems weird that the contextual filter would be throwing an error when no context is being provided to use that filter
@hilljaycie14 You reference an example feature "TEST-123". What filters is that feature registered to use?
@hilljaycie14 I took a look and here's what I've found.
Version 3.0 has introduced a behavior change, perhaps one we can consider a regression/bug.
In version 2.6.1 it was fine for a feature to reference a contextual feature filter and not use it. The system would detect that the contextual filter referenced does exist, but since no app context was provided it would simply ignore evaluating the contextual filter. It's debatable whether or not this was the right behavior to be implemented, but nonetheless it's how it worked.
v3.0 changed this. Now, if a contextual filter is referenced, but no context that can be used for the filter is passed, then the system errors.
At a glance, it seems we should allow things to work as they did in 2.6.1
@hilljaycie14 A work around solution is to set the IgnoreMissingFeatureFilters option as true.
services.Configure<FeatureManagementOptions>(options => options.IgnoreMissingFeatureFilters = true);
I am working on a PR to resolve this issue and make the behavior consistent with 2.6.1.
Sorry for the inconvenience.
I checked the behavior in 2.6.1.
Let's say you have a non-contextual filter called FilterA and a contextual filters FilterB which accepts TypeT.
You also have a feature flag "MyFeature" which references FilterA and FilterB.
Assume that IgnoreMissingFeatureFilter is false.
When you call IsEnabledAsync("MyFeature")
In 2.6.1:
The metadata of FilterA and FilterB can be found by the feature manager. No exception will be thrown.
The context is not provided, feature manager will just ignore the FilterB.
In 3.0.0:
The metadata of FilterB cannot be found by the feature manager. In 3.0.0, context type and filter alias are both needed to get the metadata of a contextual filter. An exception will be thrown.
When you call IsEnabledAsync("MyFeature", context), if context's type is TypeT
The behaviors are the same.
When you call IsEnabledAsync("MyFeature", context), if context's type is TypeF
In 2.6.1:
The metadata of FilterA and FilterB can be found by the feature manager. No exception will be thrown.
The context type TypeF cannot be consumed by FilterB, feature manager will not find a ContextualFeatureFilterEvaluator for FilterB. The evaluation of FilterB will be skipped.
In 3.0.0:
The metadata of FilterB cannot be found by the feature manager. In 3.0.0, context type and filter alias are both needed to get the metadata of a contextual filter. An exception will be thrown.
Thank you all for your quick responses, it is greatly appreciated!
@hilljaycie14 You reference an example feature "TEST-123". What filters is that feature registered to use?
The registration is as follows, some code omitted for privacy concerns:
return services.AddFeatureManagement()
.AddFeatureFilter<MyContextualFilter>()
.AddFeatureFilter<MyFeatureFilter>()
@zhiyuanliang-ms thank you for your workaround && getting a quick PR up! Greatly appreciated!
Breaking change was not reported for the following scenario
With the below configuration, when using IFeatureManager.IsEnabledAsync("FeatureToCheck")
throws an exception for the ContextualFilter instead of skipping the ContextualFilter. but when using IFeatureManager.IsEnabledAsync("FeatureToCheck", context) works fine.
"FeatureManagement": {
"FeatureToCheck": {
"RequirementType": "Any",
"EnabledFor": [
{
"Name": "ContextualFilter"
},
{
"Name": "NonContextualFilter"
}
]
}
}@MoazAlkharfan Yes, this is a breaking change. This PR #314 fixed it. We are going to release 3.1.0 in the following days. 3.1.0 will include bug fix and some other new features.
Fixed in release 3.1.0