Feature filter parameter object

[linglingye001]

Overview

This PR introduces a new ParameterObject property to FeatureFilterEvaluationContext, enabling custom IFeatureDefinitionProvider implementations to supply feature filter settings directly without requiring IConfiguration.

Motivation

Currently, feature filters receive their configuration through IConfiguration, which works well for JSON/config file-based feature definitions. However, custom IFeatureDefinitionProvider implementations that source feature definitions from alternative backends (e.g., databases, REST APIs, gRPC services) are forced to:

1. Construct an IConfiguration object from their native data format
2. Have filters bind that configuration back to strongly-typed settings objects

This round-trip is unnecessary overhead when the provider already has the ability to create strongly-typed settings objects like TargetingFilterSettings or TimeWindowFilterSettings directly.

Code Examples - Before & After

Before: Using IConfiguration with InMemoryCollection

When implementing a custom IFeatureDefinitionProvider that fetches feature definitions from a database, you previously had to construct an IConfiguration object to pass filter parameters:

// Fetch from database
var dbFeature = await _database.GetFeatureAsync(featureName);

// Must convert to IConfiguration even though we already have the data
var configData = new Dictionary<string, string>
{
    ["Audience:Users:0"] = dbFeature.TargetedUsers[0],
    ["Audience:Users:1"] = dbFeature.TargetedUsers[1],
    ["Audience:Groups:0:Name"] = dbFeature.TargetedGroups[0].Name,
    ["Audience:Groups:0:RolloutPercentage"] = dbFeature.TargetedGroups[0].RolloutPercentage.ToString(),
    ["Audience:DefaultRolloutPercentage"] = dbFeature.DefaultRolloutPercentage.ToString()
};

return new FeatureDefinition
{
    Name = featureName,
    EnabledFor = new[]
    {
        new FeatureFilterConfiguration
        {
            Name = "Targeting",
            Parameters = new ConfigurationBuilder()
                .AddInMemoryCollection(configData)
                .Build()
        }
    }
};

This approach has several drawbacks:

• Verbose dictionary key construction with magic strings
• Error-prone index management for arrays
• Unnecessary serialization to key-value pairs just to deserialize back to objects

After: Using ParameterObject Directly

With the new ParameterObject property, custom providers can supply strongly-typed settings directly:

// Fetch from database
var dbFeature = await _database.GetFeatureAsync(featureName);

// Directly create strongly-typed settings
var targetingSettings = new TargetingFilterSettings
{
    Audience = new TargetingFilterAudience
    {
        Users = dbFeature.TargetedUsers,
        Groups = dbFeature.TargetedGroups.Select(g => new GroupRollout
        {
            Name = g.Name,
            RolloutPercentage = g.RolloutPercentage
        }).ToList(),
        DefaultRolloutPercentage = dbFeature.DefaultRolloutPercentage
    }
};

return new FeatureDefinition
{
    Name = featureName,
    EnabledFor = new[]
    {
        new FeatureFilterConfiguration
        {
            Name = "Targeting",
            ParameterObject = targetingSettings  // Direct assignment!
        }
    }
};

Changes

• FeatureFilterEvaluationContext: Added ParameterObject property to hold strongly-typed settings provided by custom providers
• Built-in filters updated (PercentageFilter, TimeWindowFilter, ContextualTargetingFilter): Now check ParameterObject first before falling back to Settings or binding from Parameters

Precedence Order

When evaluating filter settings:

1. ParameterObject (if set) — Direct strongly-typed object from provider
2. Settings — Pre-bound settings via IFilterParametersBinder
3. Parameters — Bind from IConfiguration

The expectation is that systems using ParameterObject will not set Parameters/IConfiguration.

[jimmyca15]

Consider the exception that will be raised by the system if someone provides the incorrect type here. Ideally we'd like a FeatureManagementException if someone populates ParametersObject, but it's not TargetingFilterSettings

[linglingye001]

Got it. Added FeatureManagementError.InvalidParametersObject for this scenario.

[linglingye001]

Discussed offline, throw ArgumentException for incorrect type.

[jimmyca15]

Copilot's findings of "This assignment to parametersObject is useless, since its value is never read." are valid and should be addressed before merging.

[zhiyuanliang-ms]

Can we set ParametersObject to FeatureFilterEvaluationContext.Settings instead of adding a new ParametersObject property.

@jimmyca15

[jimmyca15]

I think that's a good idea. We'll need an update on the description of Settings. Something like

/// <summary>
/// A settings object, if any, provided for the feature filter to use when evaluating whether the feature should be enabled.
/// This property is populated in two cases:
/// For features that provide parameters as an object.
/// For <see cref="IFeatureFilter"/>s that implement <see cref="IFilterParametersBinder"/>.
/// </summary>

[jimmyca15]

@linglingye001

[zhiyuanliang-ms]

If we set the new parametersObject to context.settings, the code path will be more unified.