test(operators): add error return scenarios for custom operator null fallback#342
test(operators): add error return scenarios for custom operator null fallback#342
Conversation
Summary of ChangesHello, 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! This pull request enhances the testing suite by adding comprehensive scenarios for custom operator error handling. The primary goal is to ensure that when custom operators encounter invalid input or conditions, they correctly return a Highlights
Changelog
Activity
Using Gemini Code AssistThe 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
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 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
|
There was a problem hiding this comment.
Code Review
This pull request adds test scenarios to verify that custom operators correctly return null on error, leading to the default variant fallback. The changes include new flag definitions in flags/edge-case-flags.json for sem_ver and fractional operator error conditions, and corresponding test scenarios in gherkin/targeting.feature. The implementation looks correct and covers the intended error cases. I've added one suggestion to improve the conciseness of a Gherkin Scenario Outline.
…l operators Adds @operator-errors tagged scenarios verifying that custom operator errors return null (triggering default variant fallback) rather than false (which would take the false branch of a conditional): - sem_ver with an unparseable version string - sem_ver with an unknown comparison operator - fractional with a missing/null bucket key Addresses: open-feature/flagd#1874 Signed-off-by: Simon Schrottner <simon.schrottner@dynatrace.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
72a8839 to
a6a7234
Compare
|
relates too open-feature/flagd#1874 |
Summary
Adds
@operator-errorstagged scenarios totargeting.featurecovering error return behavior from flagd#1874.New Tag
@operator-errors— SDK implementations can opt in to verify their custom operators returnnull(notfalse) on error, which triggers the default variant fallback rather than the false branch of a conditional.New Scenarios
All three scenarios use flags where the targeting rule is a bare operator call (not wrapped in
if), so anullreturn triggers the default variant directly.sem_ver with unparseable version (
semver-invalid-version-flag)Context passes
not-a-version— sem_ver can't parse it, must returnnull→ default variantfallback.sem_ver with unknown operator (
semver-invalid-operator-flag)Rule uses
===which is not a valid sem_ver operator — must returnnull→ default variantfallback.fractional with missing bucket key (
fractional-null-bucket-key-flag)Context is empty — bucket key variable resolves to
null— must returnnull→ default variantfallback.Related