Rust resolver returns InternalError where Java gracefully degrades to NO_SEGMENT_MATCH

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).

Start with the four named cases in the spec tests.json files and run make -C confidence-resolver test to reproduce the Rust and Java expectations. Trace the Rust resolver paths for circular_segment_dependency, all_rule_heterogeneous, timestamp_bad_value, and empty_range_rule; done means removing each rust override lets the tests pass with the general expectation.