shortestPath/allShortestPaths with variable-length relationship type alternation may match no rows #4190

ArcadeDB version
Observed on Docker images:

• arcadedata/arcadedb:26.4.2

Environment

• Host OS: Windows 10
• Architecture: x86_64
• Deployment: Docker
• ArcadeDB endpoint: HTTP /api/v1/command/arcade
• Request mode matches ArcadeDB Studio:
  • language: opencypher
  • serializer: studio
• Differential comparison target: Neo4j Docker neo4j:latest

Describe the bug
ArcadeDB may silently return no rows when shortestPath(...) or allShortestPaths(...) uses a variable-length relationship pattern whose type is an alternation, such as:

[:R1|R2*]

This does not look like a general shortest-path failure:

• the same variable-length pattern works in an ordinary MATCH
• the same shortest-path call works with a single relationship type such as [:R1*]
• fixed-length type alternation such as [:R1|R2] also works

The failure starts specifically when shortest-path evaluation is combined with both:

• relationship type alternation, and
• variable length

To Reproduce

Setup:

CREATE (:Person {name:'Alice'})-[:R1]->(:Mid {name:'M'})-[:R2]->(:City {name:'X'});

Query:

MATCH p = allShortestPaths((:Person)-[:R1|R2*]->(:City))
RETURN size(nodes(p)) AS pathLen;

Expected behavior
Observed Neo4j result:

3

ArcadeDB should return the same single row.

Actual behavior
Observed ArcadeDB 26.4.2 result:

0 rows

So ArcadeDB behaves as if the path does not exist.

Control cases

The same pattern works correctly in an ordinary MATCH:

MATCH p = (:Person)-[:R1|R2*]->(:City)
RETURN size(nodes(p)) AS pathLen;

Observed result on Neo4j and ArcadeDB 26.4.2:

3

If the shortest-path call uses a single relationship type instead of an alternation, ArcadeDB also behaves correctly:

MATCH p = allShortestPaths((:Person)-[:R1*]->(:Mid))
RETURN size(nodes(p)) AS pathLen;

Observed result on Neo4j and ArcadeDB 26.4.2:

2

If the type alternation is kept but variable length is removed, ArcadeDB again behaves correctly:

MATCH p = allShortestPaths((:Person)-[:R1|R2]->(:Mid))
RETURN size(nodes(p)) AS pathLen;

Observed result on Neo4j and ArcadeDB 26.4.2:

2

So the bad behavior starts specifically at the combination:

• shortest-path function
• variable length
• type alternation

The same root issue also appears with shortestPath(...):

MATCH p = shortestPath((:Person)-[:R1|R2*]->(:City))
RETURN size(nodes(p)) AS pathLen;

Observed results:

• Neo4j: 3
• ArcadeDB 26.4.2: 0 rows

So this is not limited to allShortestPaths(...).

Stronger variant from the current differential

The same family first surfaced in a larger mixed-type query:

Setup:

CREATE (a:Person {name: 'Alice', age: 30, active: true}),
       (b:Person {name: 'Bob', age: 25, active: false}),
       (c:City {name: 'New York', population: 8000000}),
       (d:City {name: 'London', population: 9000000}),
       (a)-[:KNOWS]->(b),
       (a)-[:LIVES_IN]->(c),
       (b)-[:LIVES_IN]->(d);

Query:

MATCH (p:Person)
WHERE p.active = true
WITH p
OPTIONAL MATCH path = allShortestPaths((p)-[:KNOWS|LIVES_IN*]-(:City))
RETURN p.name AS name, size(nodes(path)) AS pathLen
ORDER BY pathLen;

Observed results:

• Neo4j:

Alice, 2
Alice, 3

• ArcadeDB 26.4.2:

Alice, null

Direct minimization shows that OPTIONAL MATCH is not the root cause.
The smaller failure already appears in plain MATCH p = allShortestPaths((:Person)-[:R1|R2*]->(:City)).

Why this matters
This can silently break path-based logic that relies on mixed relationship types, including:

• shortest-path exploration across heterogeneous edge classes
• optional path pipelines
• later nodes(path) / relationships(path) projections
• count and aggregation logic built on shortest-path results

with a false 0 rows / null path result instead of a matching path.