[Bug] Two query behaviors that produce the same result are inconsistent.

[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: 50 vertices, 100 edges

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

Expected behavior

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

g.E().has('ep4', lt(0.32696354)).and(__.hasLabel('el2')).count()

g.E().has('ep4', lt(0.32696354)).match(__.as('start1').and(__.hasLabel('el2')).as('m1')).select('m1').count()

Actual behavior

• The first query thrown a exception: org.apache.hugegraph.exception.NoIndexException: Don't accept query based on properties [ep4] that are not indexed in label 'el2', may not match secondary/range condition

• The second query returned the results normally.

• When I executed these two queries on Janusgraph and Tinkerpop, they both returned the same results.

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

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

[dosubot]

Hi @guijinxin! I'm Dosu and I’m helping the incubator-hugegraph team.

HugeGraph enforces index requirements differently depending on how filters are expressed in Gremlin. When you use a top-level has step (like in your first query), HugeGraph's query optimizer tries to push the filter into the backend query. If the property (like ep4) is not indexed, it throws a NoIndexException to avoid a full scan. However, when you use match or nest filters inside traversals (like your second query), those filters are applied after data retrieval as in-memory predicates, so the index check is bypassed and no exception is thrown—even though the logic is the same.

This difference is not documented as a feature, but is a result of how HugeGraph's query planner works: only filters directly following g.E()/g.V() are "hoisted" into the backend query and subject to index enforcement. Filters inside match, and, or similar steps are evaluated later, which is why you see inconsistent behavior between the two queries. Other graph databases like JanusGraph and TinkerPop do not enforce index requirements in the same way, which is why you get consistent results there.

If you want consistent behavior and performance, it's best to ensure that properties you filter on (especially with range or secondary conditions) are indexed, or be aware that using match/nested traversals may bypass index checks and lead to full scans or unexpected results. This is a known area for optimization in HugeGraph, but as of 1.7.0, this is the expected behavior given the current query planner design.

References:

• HugeGraph query optimization and index enforcement
• ConditionQuery and index checks
• HugeGraph indexing discussion

To reply, just mention @dosu.

---

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

   

[guijinxin]

@dosu Will this issue be fixed in the future?

[dosubot]

Based on everything I've found, there are currently no official plans, roadmap items, or recent work in HugeGraph to fix the inconsistent index enforcement behavior in Gremlin queries. Recent issues and pull requests do not mention this bug or any scheduled work to address it. If this changes, updates would likely appear in the repository or release notes.

To reply, just mention @dosu.

---

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

   

[LYD031106]

@dosu Will this issue be fixed in the future?

哈喽请问能提供一下测试用例吗，我可以复现分析一下原因