Summary
The Rust resolver returns InternalError (or in one case, MATCH) for several edge cases where the Java resolver gracefully degrades to NO_SEGMENT_MATCH. This means clients may get different behavior depending on which resolver implementation they hit.
Affected test cases
1. circular_segment_dependency
- Rust: Returns an error (InternalError) when evaluating circular segment references.
- Java: Returns
NO_SEGMENT_MATCH — treats the circular dependency as a non-matching segment.
2. all_rule_heterogeneous
- Rust: Returns an error on heterogeneous lists like
[10, "text", 50] in an allRule.
- Java: Returns
NO_SEGMENT_MATCH — treats the malformed rule as non-matching.
3. timestamp_bad_value
- Rust: Returns an error when encountering an empty string
"" as a timestamp value.
- Java: Returns
NO_SEGMENT_MATCH — treats the unparseable timestamp as non-matching.
4. empty_range_rule
- Rust: Returns
MATCH for a range rule with no bounds (no min, no max).
- Java: Returns
NO_SEGMENT_MATCH.
- Note: This is the inverse pattern — Rust matches where Java doesn't — but it is still a divergence in edge-case handling.
Expected behavior
The Java resolver's approach of treating these as "segment doesn't match" is more resilient — a bad segment definition or malformed data shouldn't cause a hard error for the client. Instead, it should be treated as a non-match so that flag resolution can continue and fall through to the default variant.
Validation
For each fixed test case, remove the "rust" override key from its expectedResult in tests.json. The test should then pass using the "general" expectation, confirming the Rust resolver now matches Java's behavior. Run make -C confidence-resolver test to verify.
Spec test reference
These test cases are tracked in the spec test tests.json files with "rust" override keys that document the divergent behavior. See the test names listed above.
Related
These divergences were discovered while adding conformance tests from the Java resolver (PR #335).
Summary
The Rust resolver returns
InternalError(or in one case,MATCH) for several edge cases where the Java resolver gracefully degrades toNO_SEGMENT_MATCH. This means clients may get different behavior depending on which resolver implementation they hit.Affected test cases
1.
circular_segment_dependencyNO_SEGMENT_MATCH— treats the circular dependency as a non-matching segment.2.
all_rule_heterogeneous[10, "text", 50]in anallRule.NO_SEGMENT_MATCH— treats the malformed rule as non-matching.3.
timestamp_bad_value""as a timestamp value.NO_SEGMENT_MATCH— treats the unparseable timestamp as non-matching.4.
empty_range_ruleMATCHfor a range rule with no bounds (no min, no max).NO_SEGMENT_MATCH.Expected behavior
The Java resolver's approach of treating these as "segment doesn't match" is more resilient — a bad segment definition or malformed data shouldn't cause a hard error for the client. Instead, it should be treated as a non-match so that flag resolution can continue and fall through to the default variant.
Validation
For each fixed test case, remove the
"rust"override key from itsexpectedResultintests.json. The test should then pass using the"general"expectation, confirming the Rust resolver now matches Java's behavior. Runmake -C confidence-resolver testto verify.Spec test reference
These test cases are tracked in the spec test
tests.jsonfiles with"rust"override keys that document the divergent behavior. See the test names listed above.Related
These divergences were discovered while adding conformance tests from the Java resolver (PR #335).