[TINKERPOP-2863] HasId Step generates incorrect results when given a list of IDs mid-traversal

• Type: Bug
• Status: Closed
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: 3.6.2
• Fix Version/s: 3.7.0, 3.6.3, 3.5.6
• Component/s: process
• Assignee: Yang Xia
• Reporter: Taylor Riggan
• Created: 01/Feb/23 17:46
• Updated: 21/Apr/23 01:06
• Resolved: 21/Apr/23 01:06

Description

In most situations, hasId() will accept a list of potential IDs to filter on and implicitly use within() filtering semantics to return the correct results.  Examples:

g.V().hasId(['1','2'])

returns:

[v[1], v[2]]

or

g.E().hasId(['5140','5261'])

returns:

[e[5140][1-route->51], e[5261][1-route->398]]

However, when using the same form of semantics mid-traversal, both of these queries return empty results:

g.V().has('code','ATL').outE('route').hasId(['5140','5261'])
g.V().has('code','ATL').outE('route').inV().hasId(['2','3'])

When using profile() against both queries, the hasId() bytecode gets transformed into

HasStep([~id.eq([5140, 5261])]) 

This equates to finding a vertex or edge with an ID that matches the entire list instead of the elements within the list.

The preceding was tested against Gremlin Server 3.6.2 with the Airroutes dataset.

Issue Links

• relates to: TINKERPOP-1048 Vertex lookups by id are inconsistent