Can't Upgrade to v3.0.0 - "The feature filter '' specified for feature '' was not found.

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 EvaluateAsync is 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

Jaycie Hill (@hilljaycie14)

Jaycie Hill (@hilljaycie14) You reference an example feature "TEST-123". What filters is that feature registered to use?

Jaycie Hill (@hilljaycie14)

Jaycie Hill (@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

Zhiyuan Liang (@zhiyuanliang-ms)

Jaycie Hill (@hilljaycie14)

Jaycie Hill (@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.

Jimmy Campbell (@jimmyca15)

Thank you all for your quick responses, it is greatly appreciated!

Jimmy Campbell (@jimmyca15)

Jaycie Hill (@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>()

Zhiyuan Liang (@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"
            }
        ]
    }
}

Moaz Alkharfan (@MoazAlkharfan)

Moaz Alkharfan (@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

Navigation Menu

Repository navigation

Can't Upgrade to v3.0.0 - "The feature filter '' specified for feature '' was not found. #313

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Can't Upgrade to v3.0.0 - "The feature filter '' specified for feature '' was not found. #313

Description

Activity

jimmyca15 commented on Nov 15, 2023

jimmyca15 commented on Nov 15, 2023

zhiyuanliang-ms commented on Nov 15, 2023

zhiyuanliang-ms commented on Nov 15, 2023

hilljaycie14 commented on Nov 15, 2023

MoazAlkharfan commented on Nov 21, 2023

zhiyuanliang-ms commented on Nov 21, 2023

zhiyuanliang-ms commented on Nov 23, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions