[test] Add regression test for attribute eq with no range index (issue #3964)#6323
Open
joewiz wants to merge 1 commit into
Open
[test] Add regression test for attribute eq with no range index (issue #3964)#6323joewiz wants to merge 1 commit into
joewiz wants to merge 1 commit into
Conversation
…eXist-db#3964) Guards the runtime fallback in `Lookup.canOptimize` for the case where the range query rewriter unconditionally turns `[@x eq 'val']` into `[range:eq(@x, 'val')]` even when no range index is configured for that attribute. The original report (eXist-db#3964) was that this rewrite caused the predicate to silently return zero matches; on current `develop` the fallback to the original `GeneralComparison` produces correct counts, but the rewrite step still happens, so a future regression in the fallback would be silent without this test. The fixture configures a range index on an unrelated element so the range module is active for the collection but the queried attribute remains unindexed. The test asserts that `@x eq 'val'`, `@x = 'val'`, and the doc-rooted variant all agree with the explicit `@x/string() eq 'val'` shape. Refs eXist-db#3964 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
duncdrum
reviewed
May 19, 2026
Contributor
duncdrum
left a comment
duncdrum
left a comment
There was a problem hiding this comment.
I think this would be much cleaner as xqsuite test.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a regression test in
extensions/indexes/rangefor issue #3964: an attribute predicate[@x eq 'val']on a collection step is unconditionally rewritten byRangeQueryRewriterto[range:eq(@x, 'val')], even when no range index is configured on@x. The original report was that this caused the predicate to silently return zero matches.On current
developthe bug does not reproduce: the runtime fallback inLookup.canOptimizeSequencecorrectly detects that the index is not configured for the path, setscanOptimize = false, andLookup.evaldelegates to the originalGeneralComparisonviafallback.eval(...). The rewritten AST is still produced — confirmed by inspecting the dumped AST under a debug print — but the runtime path is now correct. The five+ years of optimizer fixes since 5.3.0 most likely closed this gap incidentally; no separate fix could be identified.This PR ships the regression test as a guard so a future change to
Lookup.canOptimizecannot silently re-introduce the empty-result bug. No production code changes.What changed
extensions/indexes/range/src/test/java/org/exist/xquery/modules/range/AttributeEqIndexConsistencyTest.java— new<article-title>) so the range module is active for the collection but@contrib-id-typeitself remains unindexed — the configuration that triggers the unconditional rewrite without a usable index.[@x/string() eq 'val']:[@x eq 'val']overcollection(...)[@x = 'val']overcollection(...)(general comparison)[@x eq 'val']overdoc(...)(the shape that already worked in the original report)Why a test, not a fix
The bug shape from the issue does not reproduce — see the comment thread on #3964 — but the rewrite-path the report identified is still active in current code. This test exercises that path so any regression in the fallback would now fail loudly rather than silently returning zero matches.
Test plan
mvn test -pl extensions/indexes/range— 425 pass, 0 failures, 3 skipped (the new class contributes 3)Refs #3964