[Bug] Unexpected IllegalArgumentException for gte()-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.E().bothV().where(__.out('el0').count().is(gte(-3))).count()

g.E().match(__.as('start0').repeat(__.bothV()).times(1).as('m0')).select('m0').match(__.as('start1').where(__.out('el0').count().is(gte(-3))).as('m1')).select('m1').count()

Actual behavior

• The first query thrown a exception: java.lang.IllegalArgumentException: Not a legal range: [0, -3]
• The second query returned the results normally.
• We replaced the bothV() step in the first query with match(__.as('start0').repeat(__.bothV()).times(1).as('m0')).select('m0'), and moved thewhere (...) step into the match()step. Both of these operations 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.

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

none

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

none

[dosubot]

This exception is caused by HugeGraph's internal range validation logic, not by the gte() predicate itself. When you use count().is(gte(-3)), HugeGraph tries to construct a query range with [0, -3], which fails validation because the end of the range is less than the start. The relevant code enforces that range queries must have end >= start, and throws IllegalArgumentException if not, resulting in the error you see ["Invalid range: 0, -3)".

This behavior is different from JanusGraph and Tinkerpop, which do not reject negative values in this context. In HugeGraph, you can avoid this error by not using negative values in range predicates like gte() when they are applied to steps that result in a count or range operation. Alternatively, restructuring the query (as in your second example) avoids triggering this range validation path.

There are currently no merged fixes or workarounds in recent HugeGraph releases for this issue, so this is likely a bug or an unintended limitation in the query optimizer.

To reply, just mention @dosu.

---

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