IFeatureManagerSnapshot one flag, many contexts. about featuremanagement-dotnet HOT 4 CLOSED

Looks like this is by design :(. Not perfect imo.

Here is the code

    public async Task<bool> IsEnabledAsync<TContext>(string feature, TContext context)
    {
        //
        // First, check local cache
        if (_flagCache.ContainsKey(feature))
        {
            return _flagCache[feature];
        }

        bool enabled = await _featureManager.IsEnabledAsync(feature, context).ConfigureAwait(false);

        _flagCache[feature] = enabled;

        return enabled;
    }

from featuremanagement-dotnet.

@PiotrJustyna

The IFeatureManagerSnapshot is purposefully naïve when it comes to feature contexts. We would need a way to check for equality between contexts to be able to do anything further, and this would've required every context to implement an interface that we provide. This is not always possible so we decided not to impose this limitation. Our thoughts were that in general, if IFeatureManagerSnapshot would be useful in combination with feature contexts, then the lifetime of the feature manager snapshot would be in line with the lifetime of the feature context.

from featuremanagement-dotnet.

Another option we have is to allow Object.Equals to play the role of establishing context equality. This may solve the problem.

I do want to call out another factor that was considered. Caching an object passed in while evaluating the feature may have unintended consequences since callers might not necessarily be expecting the lifetime of the object to now be tied to the snapshot. It's something we'd want to consider if we did take the approach I just mentioned.

from featuremanagement-dotnet.

Thanks @jimmyca15, I guess that is fair enough. It would be great so see a bit more sophistication in how the manager operates, but I suppose I can live with it the way it is now.

I did experiment with Object.Equals as I was formulating the linked PR, but it could be costly and since the contexts are not so strictly defined, it could lead to the equality comparisons being open to interpretation by engineers. I proposed a simple solution which just requires contexts to have IDs so that they can be easily compared with no ambiguity to what is actually being compared. Not feeling too strongly about this change, but I'm sure it is going to prove useful to some. I will close the PR as I plan to close this issue as well.

from featuremanagement-dotnet.