Repository navigation
[Bug] Unexpected ArrayIndexOutOfBoundsException for filter-step and repeat()-step #2935
Description
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 the
has(...)step andrepeat()step in first query into thematch()step and replace therepeat()withunion()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 (问题点 / 边数据举例)
noneSchema [VertexLabel, EdgeLabel, IndexLabel] (元数据结构)
none
Activity
dosubot commentedon Jan 7, 2026
This is a known HugeGraph 1.7.0 bug: top-level filter steps (like
has()withrepeat()) can throw exceptions such asArrayIndexOutOfBoundsException, while equivalent queries usingmatch()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.,NestedIteratororHugeTraverser) tries to access an array index that doesn't exist, causing the exception. In contrast, filters insidematch()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.
Share context across your team and agents. Try Dosu.