[Bug] NoIndexException triggered by match()-step

[guijinxin]

Bug Type (问题类型)

gremlin (结果不合预期)

Before submit

• 我已经确认现有的 Issues 与 FAQ 中没有相同 / 重复问题 (I have confirmed and searched that there are no similar problems in the historical issue and documents)

Environment (环境信息)

• Server Version: 1.7.0
• Backend: RocksDB x nodes
• OS: 192 CPUs, 256 G RAM, Ubuntu 22.04
• Data Size: 10 vertices, 20 edges

Expected & Actual behavior (期望与实际表现)

Expected behavior

For the two query below, the same result should be returned:

g.V().has('vp4', neq('J2O')).has('vl1', 'vp2',gte(false)).has('vp2').has('vl0', 'vp3',gt(4592737712018141718)).out().count()

g.V().has('vp4', neq('J2O')).has('vl1', 'vp2',gte(false)).match(__.as('start0').has('vp2').has('vl0', 'vp3',gt(4592737712018141718)).repeat(__.out()).times(1).as('m0')).select('m0').count()

Actual behavior

• The first query returned the results normally.
• The second query thrown a exception: org.apache.hugegraph.exception.NoIndexException: Don't accept query based on properties [vp4, vp2] that are not indexed in label 'vl1', may not match secondary/range/not-equal condition

• We moved thehas(...) step and out()step in first query into the match()step and replace the out() with repeat() step, which should not affect the result.
• When I executed these two queries on Janusgraph and Tinkerpop, they both returned the same results and were consistent with the results of the first query.
• I have implemented a fuzzing tool and am using it to test HugeGraph. To reduce the burden on developers, I have simplified the test cases as much as possible and isolated irrelevant information. I hope this work can be helpful for further improving the stability of HugeGraph.

Vertex/Edge example (问题点 / 边数据举例)

none

Schema [VertexLabel, EdgeLabel, IndexLabel] (元数据结构)

none

[dosubot]

This is a known limitation in HugeGraph 1.7.0. The NoIndexException occurs because HugeGraph enforces strict index requirements for properties used in filters, especially for secondary, range, and not-equal conditions. When these filters appear inside a match() or repeat() step, HugeGraph's query planner treats them differently from top-level has() steps: filters inside match()/repeat() are evaluated in-memory after data retrieval, but the backend still checks for required indexes and throws NoIndexException if they're missing. In contrast, top-level filters are pushed into the backend query and may behave differently depending on the traversal structure. This leads to inconsistent behavior between logically equivalent queries using out() versus match()/repeat() steps, unlike JanusGraph or TinkerPop, which do not enforce index requirements in the same way and return consistent results for both forms. There is currently no official fix or workaround; this is a known area for improvement in HugeGraph's query planner design as of 1.7.0. For now, ensure all filtered properties are indexed or use query forms that avoid triggering this limitation.
See related discussion and technical details

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[guijinxin]

As far as I know, this is the first time that a related exception has occurred in the match()-step report. I haven't found it in any of the previous issues. Is the code related to this bug issue identifiable? Maybe I can try to handle it in the future. @dosu

[dosubot]

Yes, the code related to this bug is identifiable. The core logic for index enforcement and the NoIndexException is in ConditionQuery.java, which manages query conditions and checks if properties used in filters (like not-equal, range, or secondary conditions) are indexed. If not, it throws exceptions such as NoIndexException. The relevant methods include hasNeqCondition(), hasRangeCondition(), hasSecondaryCondition(), and test(), which applies all conditions and triggers the exception if requirements aren't met. See ConditionQuery.java.

For traversal optimization, HugeVertexStepStrategy.java is responsible for extracting filter conditions from the main traversal and pushing them into backend queries. However, it does not extract or optimize filters inside nested traversals like match() or repeat(), which is why index enforcement behaves differently in those cases. See HugeVertexStepStrategy.java.

If you want to address this bug, you would likely need to enhance how HugeVertexStepStrategy (and related traversal utilities) extract and enforce filter conditions from nested traversals, not just the top-level steps. This is a known area for improvement in HugeGraph's query planner design and has been discussed in related issues and threads (example).

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}