Refine variant reason computation to include SPLIT and STATIC#11037
Open
Refine variant reason computation to include SPLIT and STATIC#11037
Conversation
…ng TARGETING_MATCH - Add Split parameter to resolveVariant for three-way reason computation - Return STATIC for flags with no rules and no shards (simple flags) - Return SPLIT for flags with no rules but with shards (shard-based flags) - Return TARGETING_MATCH for flags with rules (rule-based flags) - Update 9 test assertions: 7 to STATIC, 2 to SPLIT
typotter
requested review from
dd-oleksii and
sameerank
and removed request for
a team
Contributor
|
Hi! 👋 Thanks for your pull request! 🎉 To help us review it, please make sure to:
If you need help, please check our contributing guidelines. |
typotter
changed the title
sameerank
approved these changes
Apr 2, 2026
Comment on lines
+362
to
+365
| .reason( | ||
| !isEmpty(allocation.rules) | ||
| ? Reason.TARGETING_MATCH.name() | ||
| : !isEmpty(split.shards) ? Reason.SPLIT.name() : Reason.STATIC.name()) |
dd-oleksii
added
type: enhancement
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What Does This Do
Computes the correct OpenFeature evaluation reason from the UFC allocation structure instead of hardcoding
TARGETING_MATCHfor all successful evaluations.Three-way logic in
resolveVariant():STATIC— no rules, no shards (unconditional allocation)SPLIT— no rules, shards present (percentage-based traffic split)TARGETING_MATCH— rules present (flag matched a targeting rule)Also fixes one test assertion that needed updating after rebasing onto #10990: a null targeting key on a static flag now correctly evaluates as
STATICrather thanTARGETING_MATCH.Motivation
System tests
Test_FFE_Eval_Metric_Basic(expectsreason=static) andTest_FFE_Eval_Reason_Split(expectsreason=split) were failing because the evaluator hardcodedTARGETING_MATCHregardless of allocation structure. This aligns Java behavior with the Python and Go SDK reference implementations.Co-authored-by: Leo Romanovsky leo.romanovsky@datadoghq.com (original fix in #10971)
Additional Notes
The
splitobject is passed intoresolveVariant()so the reason can be derived at resolution time without additional lookups.The semantic question of whether a catch-all (no-rules, no-shards) allocation inside a multi-allocation flag should return
STATICvs another reason is out of scope here — that's a pre-existing behavior question tracked separately.Contributor Checklist
type:and (comp:orinst:) labels in addition to any other useful labelsclose,fix, or any linking keywords when referencing an issueUse
solvesinstead, and assign the PR milestone to the issue