feat: Make defaultVariant and value optional

[marcozabel]

This PR

Updates the test cases to use the DEFAULT reason if no defaultVariant was set or the targeting rules did not evaluate a match.

Related Issues

open-feature/flagd#1856

Notes

Follow-up Tasks

How to test

[gemini-code-assist]

Summary of Changes

Hello @marcozabel, I'm Gemini Code Assist¹! 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!

This pull request refines the flag evaluation process by ensuring that when a defaultVariant is not explicitly defined or when targeting rules fail to produce a match, the flag evaluation correctly reports a DEFAULT reason. This change improves the clarity of flag resolution outcomes, moving away from an ERROR state in such scenarios, and is reflected in updated Gherkin test cases.

Highlights

• Test Case Updates: Updated existing test cases in gherkin/evaluation.feature to align with the new behavior where a DEFAULT reason is returned when no defaultVariant is set or targeting rules do not evaluate a match.
• Reason and Error Code Changes: Modified the expected reason from ERROR to DEFAULT and removed the FLAG_NOT_FOUND error_code for scenarios where flags resolve to a default state due to missing defaultVariant or targeting rule mismatches.

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 by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

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 pull request 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. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

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

1. 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. ↩

[gemini-code-assist]

Code Review

This pull request updates Gherkin test cases to reflect a change in behavior for flags without a defaultVariant. The new expectation is to return a DEFAULT reason instead of a FLAG_NOT_FOUND error. The changes in the test scenarios correctly capture this new logic. My review includes suggestions to remove a couple of redundant test cases that were introduced as a result of these changes, which will help improve the clarity and maintainability of the test suite.

[leakonvalinka]

I think we only want to change the reason column to DEFAULT here and leave the default column as it was. The way I understood the task described in the issue is that we only want to make the defaultVariant optional, but not the code-default value (= the default column here), because that's what we want to fall back to if no targeting variant matches/exists + no default variant exists either.

[leakonvalinka]

Looks good to me now

[toddbaert]

Suggested change

	And the reason should be "<reason>"
	And the reason should be "<reason>"
	And the variant should be null

@marcozabel @leakonvalinka I think one of the new differences in the spec is we will be explicitly not setting the variant in the no-default cases. I'm not 100% sure if what I've suggested above is the best way to do this matcher (it does match an existing step in the suite already) or if we need a new step like "And the variant should not be set" (depends on how easy the unquoted null will be compared to the existing matcher in the language implementations).

[leakonvalinka]

We cannot add this simple step because for one of the scenarios (TARGETING MATCH) the variant is set, so we would need to make it another variable. I'm not sure how the null is handled either, we will have to try it out I guess :D