[Bug] Unexpected NumberFormatException for filter-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().where(__.has('ep5', lt(true)))

g.E().match(__.as('start1').where(__.has('ep5', lt(true))).as('m1')).select('m1')

Actual behavior

• The first query thrown a exception: java.lang.NumberFormatException: Character t is neither a decimal digit number, decimal point, nor "e" notation exponential mark.
• The second query returned the results normally.

Additional Context

• We moved thewhere (...) step in first query into the match()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 confirmed HugeGraph-specific bug: when you use a filter like lt(true) outside of a match() step, HugeGraph tries to convert the boolean true to a number (BigDecimal), which throws a NumberFormatException because "true" is not numeric. This happens due to HugeGraph's internal comparison logic for the lt predicate, which expects a numeric or date value and forcibly converts the operand to a number, unlike JanusGraph or TinkerPop, which allow boolean comparison via Comparable.compareTo without forced numeric conversion. That's why your query works in JanusGraph/TinkerPop and inside match(), but fails in HugeGraph outside of it.

There is currently no fix or workaround in HugeGraph except to avoid using boolean values with numeric predicates like lt, or to use the match() pattern, which is handled differently internally and does not trigger the conversion bug. No recent releases or pull requests address this issue yet.

Reference:

• HugeGraph's comparison logic and forced numeric conversion
• NumericUtil and NumberFormatException root cause

To reply, just mention @dosu.

---

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