fix: added defaultVariant type validation for Resolve<T> and ResolveAll #1707
Conversation
…ll to fix inconsistency between them Signed-off-by: Andrey <[email protected]>
✅ Deploy Preview for polite-licorice-3db33c canceled.
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @andreyturkov, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
I've implemented a fix to address an inconsistency in how Resolve and ResolveAll functions handle defaultVariant types. This change introduces robust type validation to ensure that the type of the defaultVariant matches the expected type during flag resolution, preventing potential type mismatch errors.
Highlights
- Enhanced Type Validation: I've enhanced the type validation for defaultVariant values during flag resolution, ensuring that the resolved type consistently matches the expected type.
- Function Signature Updates: I've modified the signatures of the variantEvaluator and evaluateVariant functions to explicitly pass expected type information, enabling more precise type checking.
- New Type Identification Utility: I've introduced a new helper function, getTypeName, to dynamically identify and return the string representation of a value's type at runtime.
- Comprehensive Unit Testing: I've added comprehensive unit tests to cover scenarios involving mixed-type variants, thoroughly validating the new type consistency checks.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request introduces type validation for the defaultVariant in Resolve�<T�> and ResolveAll. The changes ensure that the type of the defaultVariant is consistent with the type being resolved, preventing potential runtime errors. The implementation in core/pkg/evaluator/json.go is clean and effective. A comprehensive test suite has been added in core/pkg/evaluator/json_test.go to cover these new validation scenarios. My only feedback is to improve the clarity of some test case names to avoid future confusion.
| tests := []struct { | ||
| name string | ||
| tc testCase | ||
| }{ | ||
| { | ||
| name: "defaultVariant=off, request_id=42 (should resolve to 'on', type mismatch for bool, ok for int)", | ||
| tc: testCase{ | ||
| config: flagConfigBoolDefault, | ||
| context: map[string]interface{}{"request_id": 42}, | ||
| expectBoolErr: true, | ||
| expectIntErr: true, | ||
| expectIntVal: 1, | ||
| expectIntReason: model.ErrorReason, | ||
| expectBoolReason: model.ErrorReason, | ||
| expectAllType: "bool", // fallback to default type (off=false) | ||
| expectAllReason: model.ErrorReason, | ||
| }, | ||
| }, | ||
| { | ||
| name: "defaultVariant=off, request_id=420 (should resolve to 'off', ok for bool, type mismatch for int)", | ||
| tc: testCase{ | ||
| config: flagConfigBoolDefault, | ||
| context: map[string]interface{}{"request_id": 420}, | ||
| expectBoolErr: false, | ||
| expectBoolVal: false, | ||
| expectBoolReason: model.TargetingMatchReason, | ||
| expectIntErr: true, | ||
| expectAllType: "bool", | ||
| expectAllReason: model.TargetingMatchReason, | ||
| }, | ||
| }, | ||
| { | ||
| name: "defaultVariant=on, request_id=42 (should resolve to 'on', ok for int, type mismatch for bool)", | ||
| tc: testCase{ | ||
| config: flagConfigIntDefault, | ||
| context: map[string]interface{}{"request_id": 42}, | ||
| expectIntErr: false, | ||
| expectIntVal: 1, | ||
| expectIntReason: model.TargetingMatchReason, | ||
| expectBoolErr: true, | ||
| expectAllType: "double", | ||
| expectAllReason: model.TargetingMatchReason, | ||
| }, | ||
| }, | ||
| { | ||
| name: "defaultVariant=on, request_id=420 (should resolve to 'off', type mismatch for int, ok for bool)", | ||
| tc: testCase{ | ||
| config: flagConfigIntDefault, | ||
| context: map[string]interface{}{"request_id": 420}, | ||
| expectIntErr: true, | ||
| expectBoolErr: true, | ||
| expectBoolReason: model.ErrorReason, | ||
| expectAllType: "double", | ||
| expectAllReason: model.ErrorReason, | ||
| }, | ||
| }, | ||
| } |
There was a problem hiding this comment.
The names for a couple of test cases here are a bit misleading as they don't seem to match the test's expectations. This could be confusing for future maintainers.
- The test case
"defaultVariant=off, request_id=42...ok for int)"(line 1746) suggests resolving as an integer is okay, but the test correctly expects an error (expectIntErr: true). - Similarly,
"defaultVariant=on, request_id=420...ok for bool)"(line 1786) suggests resolving as a boolean is okay, but the test expects an error (expectBoolErr: true).
This is because the new validation logic correctly identifies a type mismatch with the defaultVariant's type.
To improve clarity, could you update the names to reflect that a type mismatch is expected?
Signed-off-by: Andrey <[email protected]>
Signed-off-by: Andrey <[email protected]>
Signed-off-by: Andrey <[email protected]>
|
@andreyturkov this has been marked as draft for a while - do you still intend to do it, or have some specific concerns preventing you from fully opening it? |
@toddbaert thanks for reminder. It should addressed by #1746. So I close the PR. |
2 participants
This PR
Added defaultVariant type validation for Resolve and ResolveAll to fix inconsistency between them
Related Issues
Fixes #1481
Notes
Fixed formatting in the json_test.go (part of the file has spacing formatting, another part used tabs)
How to test
Added json_test.go/TestMixedTypeVariants_TypeConsistency covering the scenario described in #1481.