fix: remove if-wrappers from operator error flags#368
Conversation
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
There was a problem hiding this comment.
Code Review
This pull request refactors flag targeting configurations by removing redundant if wrappers and updating variant names across testkit-flags.json and edge-case-flags.json. However, multiple review comments point out that for boolean-returning operators—specifically sem_ver, starts_with, and ends_with—renaming variants to match will break the evaluator's ability to resolve results. It is recommended to retain the true and false variants to ensure proper targeting resolution and to distinguish valid matches from error states.
| "semver-invalid-operator-flag": { | ||
| "state": "ENABLED", | ||
| "variants": { "true": "true", "false": "false", "fallback": "fallback" }, | ||
| "variants": { "match": "match", "fallback": "fallback" }, |
There was a problem hiding this comment.
For boolean-returning operators like sem_ver, the variants should remain "true" and "false" to correctly handle valid results and preserve the distinction from null errors, as intended in the PR description.
| "variants": { "match": "match", "fallback": "fallback" }, | |
| "variants": { "true": "true", "false": "false", "fallback": "fallback" }, |
There was a problem hiding this comment.
These are edge cases. We WANT to test for null returns.
| "ends-with-non-string-flag": { | ||
| "state": "ENABLED", | ||
| "variants": { "true": "true", "false": "false", "fallback": "fallback" }, | ||
| "variants": { "match": "match", "fallback": "fallback" }, |
There was a problem hiding this comment.
| "match": "match", | ||
| "fallback": "fallback" |
| "match": "match", | ||
| "fallback": "fallback" |
| "match": "match", | ||
| "fallback": "fallback" |
| "match": "match", | ||
| "fallback": "fallback" |
The
ifwrappers were added in #356 (my bad), but json-logic'sifcoerces its condition to a boolean;nullandfalseare both falsy, so theifalways selects the"false"variant for both cases. This makes it impossible to verify that operators returnnull(notfalse) on error, which is the entire point of the@operator-errorsscenarios.By using the operator directly as the top-level targeting expression, a
nullreturn propagates to the evaluator, which falls back todefaultVariantwith reasonDEFAULT; afalsereturn would resolve to the"false"variant with reasonTARGETING_MATCH. The distinction is preserved.I tested this locally and with this and the expected fixes, I was able to get the test suite fully updated in in-process mode! No more inconsistencies!