[Bug] Unexpected "Illegal key 'LABEL'..." happens

[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().inE('el0').hasLabel('el0','el2').hasLabel('el1')

g.V().match(__.as('start1').repeat(__.inE('el0')).times(1).as('m1')).select('m1').hasLabel('el0','el2').hasLabel('el1')

Actual behavior

• The first query thrown a exception: java.lang.IllegalStateException: Illegal key 'LABEL' with more than one value: [1, 3]
• The second query returned the results normally.
• We replaced the inE('el0') step in the first query with match(__.as('start1').repeat(__.inE('el0')).times(1).as('m1')).select('m1'), 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.
• This issue was previously resolved in fix: can't query edges by multi labels + properties #1737 (comment), but it has occurred again.

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

none

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

none

[dosubot]

This is a known inconsistency in HugeGraph 1.7.0. The IllegalStateException about "Illegal key 'LABEL' with more than one value" is actually thrown by TinkerPop's Gremlin layer, not HugeGraph itself. It happens because HugeGraph's query planner pushes top-level label filters (like in your first query) into the backend, which triggers stricter validation and sometimes exceptions. In contrast, when you use match or nest the filters (like your second query), HugeGraph applies those filters in-memory after retrieving the data, so the exception doesn't occur and results are returned as expected. Other graph databases like JanusGraph and TinkerPop don't have this inconsistency—they return consistent results for both query forms.

There is no recent fix or workaround documented for this specific regression. The best approach for now is to use the query form that works (e.g., using match or nested traversals) and avoid the problematic pattern with top-level multiple label filters after inE() or similar steps. This behavior is a result of HugeGraph's current query planner design and is not unique to your case—other users have reported similar inconsistencies between equivalent queries in HugeGraph 1.7.0.
Reference

To reply, just mention @dosu.

---

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