[TINKERPOP-2911] CountStrategy converts count().is(0) wrongly under ConnectiveStrategy

• Type: Bug
• Status: Closed
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: 3.4.13, 3.6.2, 3.5.5
• Fix Version/s: 3.7.0, 3.6.3, 3.5.6
• Component/s: process, test-suite
• Assignee: Ken Hu
• Reporter: Norio Akagi
• Created: 17/Mar/23 17:16
• Updated: 17/Apr/23 17:11
• Resolved: 17/Apr/23 17:11

Description

A query example:

// 2nd branch is just a dummy, and assuming we don't have an edge with label "none"
g.V().where(or(out("none").out().count().is(0), has("none"))) 

Here, CountStrategy tries to convert count().is(0) to not(...). However, when it is under ConnectiveStrategy, it tries to read Steps from tail to beginning and include Steps until it finds the first non-filter Step. So in this case, it becomes

[GraphStep(vertex,[]), OrStep([[VertexStep(OUT,[none],vertex), NotStep([VertexStep(OUT,edge)])], [TraversalFilterStep([NeptunePropertiesStep([none],property)])]])]

So the first out("none") is outside of NotStep, whereas the 2nd out() is inside.
The original intention of this query is that the 1st branch under or should return true in the first branch, because there is no such edge with the label "none" and count = 0.

However this optimization returns the opposite result. Because the first VertexStep(OUT,[none],vertex) is now outside of NotStep, the 1st branch returns false.

It seems this logic was intentionally introduced while back ago
https://github.com/apache/tinkerpop/commit/36bd2a2447529371d950b2df6de36ea49957ab55

So just reverting this change may not be the permanent fix. We should investigate what should be the correct behavior for CountStrategy to apply under ConnectivityStep.