[Bug] Wrong result for where(count().is()

[choeoe]

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:
  • core: 1.7.0
  • gremlin: 3.5.1
  • api: 0.71.0.0
• Docker Image: hugegraph/hugegraph:latest
• Backend: default Docker standalone backend
• Data Size: 2 vertices, 1 edge

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

HugeGraph returns wrong results when a where() child traversal uses count().is(...).

Minimal graph:
(a:A)-[:E]->(b:A)

Bug-triggering query:
g.V('a')
.where(__.both('E').count().is(not(outside(1,18).and(gte(0)))))
.count()

Expected:
[1]

Actual:
[0]

The dual predicate is also wrong:
g.V('a')
.where(__.both('E').count().is(outside(1,18).and(gte(0))))
.count()

Expected:
[0]

Actual:
[1]

For count = 1, outside(1,18) is false, so outside(1,18).and(gte(0)) should be false, and not(...) should be true.

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

**Vertex/Edge example**



curl -fsS --compressed -X DELETE \
  "http://127.0.0.1:8080/graphs/hugegraph/clear?confirm_message=I'm%20sure%20to%20delete%20all%20data"

curl -fsS --compressed -H 'Content-Type: application/json' -X POST \
  -d '{"id":"a","label":"A","properties":{}}' \
  "http://127.0.0.1:8080/graphs/hugegraph/graph/vertices"

curl -fsS --compressed -H 'Content-Type: application/json' -X POST \
  -d '{"id":"b","label":"A","properties":{}}' \
  "http://127.0.0.1:8080/graphs/hugegraph/graph/vertices"

curl -fsS --compressed -H 'Content-Type: application/json' -X POST \
  -d '{"label":"E","outV":"a","outVLabel":"A","inV":"b","inVLabel":"A","properties":{}}' \
  "http://127.0.0.1:8080/graphs/hugegraph/graph/edges"

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

**Schema**



curl -fsS --compressed -H 'Content-Type: application/json' -X POST \
  -d '{"name":"A","id_strategy":"CUSTOMIZE_STRING","properties":[],"nullable_keys":[],"enable_label_index":true}' \
  "http://127.0.0.1:8080/graphs/hugegraph/schema/vertexlabels"

curl -fsS --compressed -H 'Content-Type: application/json' -X POST \
  -d '{"name":"E","source_label":"A","target_label":"A","frequency":"SINGLE","properties":[],"nullable_keys":[],"enable_label_index":true}' \
  "http://127.0.0.1:8080/graphs/hugegraph/schema/edgelabels"

[dosubot]

Hi @choeoe! I'm Dosu and I'm helping the HugeGraph team.

This looks closely related to your other issue #3084 and likely shares the same root cause. HugeGraph uses a custom HugeCountStrategy (introduced in PR #2993 to replace TinkerPop's unsafe CountStrategy) that rewrites count().is(...) predicates for optimization [1]. A follow-up PR #3037 fixed handling of ConnectiveStep (and()/or()) child traversals within this strategy [2].

However, the specific combination of NotP wrapping a nested ConnectiveP — i.e., not(outside(1,18).and(gte(0))) — appears to be an uncovered edge case. Looking at the predicate conversion code in TraversalUtil, NotP is not explicitly handled in the convHas2Condition() method [3], meaning the negation logic likely relies on TinkerPop's default handling, which may interact incorrectly with HugeGraph's count optimization rewriting.

The relevant code is in:

• HugeCountStrategy.java — handles count optimization and not() rewriting for the where() pattern
• TraversalUtil.java — handles predicate conversion, including convAnd() and convOr() for compound predicates

Since PR #3037 was merged on 2026-06-08 and the hugegraph/hugegraph:latest Docker image you're using is version 1.7.0, you may not have this fix. But even with that PR, the NotP + nested ConnectiveP combination (not(outside().and())) doesn't appear to be covered by the added tests (testConnectiveAndCountIsZero, testConnectiveOrCountIsZero).

This is likely a gap in the HugeCountStrategy rewriting logic when it encounters NotP containing a ConnectiveP child — the negation isn't correctly propagated through the compound predicate during the count optimization pass.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.