[Bug] Unexpected ArrayIndexOutOfBoundsException for filter-step and repeat()-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: 50 vertices, 100 edges

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

Expected behavior

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

g.V().has('vp4', lt('')).repeat(__.out('el2')).emit().times(1).count()
g.V().match(__.as('start').has('vp4', lt('')).union(__.out('el2')).as('m')).select('m').count()

Actual behavior

• The first query thrown a exception: java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
• The second query returned the results normally.

Additional Context

• We moved thehas(...) step and repeat()step in first query into the match()step and replace the repeat() with union() 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 second 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.

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

none

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

none

[dosubot]

This is a known HugeGraph 1.7.0 bug: top-level filter steps (like has() with repeat()) can throw exceptions such as ArrayIndexOutOfBoundsException, while equivalent queries using match() or nested traversals work as expected. The root cause is that HugeGraph's query planner pushes top-level filters into backend queries and expects certain label/property arrays to be non-empty; when they're empty (as in your query), the traversal engine (e.g., NestedIterator or HugeTraverser) tries to access an array index that doesn't exist, causing the exception. In contrast, filters inside match() are applied in-memory after data retrieval, bypassing this bug. Other graph databases like JanusGraph and TinkerPop do not have this inconsistency, so both query forms work there.

There is no fix or official workaround in 1.7.0, but rewriting your query to use match() or nested traversals avoids the exception and returns the expected result. This pattern has been reported by other users for similar query forms and is a limitation of HugeGraph's current query planner and filter handling.
See related discussion and technical details

To reply, just mention @dosu.

---

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