Add Default Variant

[GeorgeMac]

Problem

Currently, it is technically possible through the API or via the declarative backend to create a variant flag with a segment matching rule that has zero distributions (the UI blocks this). What this leads to is that a context which does match the segment for the rule returns Match == false, because matched has historically implied there is also an associated variant to return. However, variants are only selected when there is a distribution that the request entity ID hashes into. So given no distributions, the engine cannot reliably pick a variant and so it returns a result as having no match.

See this attempt to change the bahaviour of the evaluation engine in this situation: #2979

Ideal Solution

We could add a new property to variant flags to identify a default variant. This would be an optional additional parameter. It would identify one of its variants as being the variant to choose, given no distributions match for the entity ID.

How we represent the default variant could be one of a couple ways:

1. Add a default_variant key to flag. It should contain a key which is present in the variants set within the flag itself. We would need to ensure this constraint is maintained both when adding a default or removing a referenced variant.
2. Add a default boolean field to the Variant type itself. This removes the need to maintain the constraints required in (1), however, it introduces a different constraint, that we need to validate and maintain that default is only for one member of the flags entire set of variants.

Making the default variant an opt-in parameter would ensure backwards compatibility. Attempting to infer a default would be a breaking change and could cause unexpected behaviour. So making this opt-in is important.

Search

• I searched for other open and closed issues before opening this

Additional Context

No response