Option to filter variants by matching ALL overrides, not only ANY

[samuelneff]

Describe the feature request

We would like to create some complex scenarios that require filtering variants based on multiple overrides matching, not based on any one of multiple overrides matching.

Background

Significantly more detail and background available in previous discussion: https://github.com/orgs/Unleash/discussions/3224.

Solution suggestions

Default behavior could remain the same of course, but an option in the SDK to specify either per-call, per flag, or per-client that variant overrides should be implemented such that all must match.

/*
    Feature flag `allocation-policy` configured with these variants and overrides:

Name                    Overrides                           Value 
------------------      ------------------------------      ----------------
default                 *none*                              never
corp                    office=corp                         lowest-load
boston                  office=boston                       round-robin
boston-managers         office=boston, role=manager         never
    Then we can expect this kind of result with the provided overrides:
*/
val unleash = Unleash.....overrideMatchingPolicy(OverrideMatchingPolicy.MATCH_ALL)

unleash.getVariant(
    "allocation-policy",
    mapOf("office" to "boston")
)

    // Result: `round-robin`, it matched override `boston` but not `manager`,
    // so `never` is not a valid option here


unleash.getVariant(
    "allocation-policy",
    mapOf(
        "office" to "boston",
        "role" to "manager"
    )
)

    // Result: `never`, it matches both overrides `boston` and `manager`,
    // so it will always return `never`


unleash.getVariant("allocation-policy")

    // Result: `lowest-load`, no overrides matched / provided

[sighphyre]

Thanks so much for raising this! I think this would be a really nice feature to add.

Just to be clear here, from the description this sounds like this would be a property set on the SDK at startup which would force all variants to use the match_all behaviour. Would it break your use case if this was driven from configuration in the UI on a per variant basis? I want to say that should reduce the risk of different configurations on multiple SDKs and make this a little more flexible to use

[samuelneff]

Would it break your use case if this was driven from configuration in the UI

UI driven config would be much better; it's just touching more things. For official implementation I agree that would be best though.