ArcadeDB version
Observed on Docker images:
arcadedata/arcadedb:26.3.2
arcadedata/arcadedb:26.4.1-SNAPSHOT
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 evaluate a relationship type predicate such as b:KNOWS as false even after b has already been bound by a relationship pattern.
In the minimized repro below:
- the pattern
MATCH (a)-[b]->(c) clearly binds two relationships
- both of those relationships are of type
KNOWS
Neo4j therefore returns both rows.
ArcadeDB instead returns zero rows.
This does not look like a general relationship-type problem:
- the equivalent typed pattern
MATCH (a)-[b:KNOWS]->(c) works
- the equivalent filter
WHERE type(b) = 'KNOWS' also works
So the failure appears specific to the relVar:TYPE predicate form after the relationship variable is already bound.
To Reproduce
Setup:
CREATE (n1:Person {name: 'Alice'}),
(n2:Person {name: 'Bob'}),
(n3:Person {name: 'Charlie'});
MATCH (n1:Person {name: 'Alice'}), (n2:Person {name: 'Bob'})
CREATE (n1)-[:KNOWS]->(n2);
MATCH (n2:Person {name: 'Bob'}), (n3:Person {name: 'Charlie'})
CREATE (n2)-[:KNOWS]->(n3);
Query:
MATCH (a)-[b]->(c)
WHERE b:KNOWS
RETURN count(b) AS cnt;
Expected behavior
Neo4j returns:
ArcadeDB should return the same result.
Actual behavior
Observed ArcadeDB result on all tested versions:
So the bound relationship variable b is treated as if it were not of type KNOWS, even though both matched relationships are KNOWS.
Control cases
If the relationship type is expressed directly in the pattern, ArcadeDB behaves correctly:
MATCH (a)-[b:KNOWS]->(c)
RETURN count(b) AS cnt;
Observed result on Neo4j and all tested ArcadeDB versions:
If the same check is expressed using type(b), ArcadeDB also behaves correctly:
MATCH (a)-[b]->(c)
WHERE type(b) = 'KNOWS'
RETURN count(b) AS cnt;
Observed result on Neo4j and all tested ArcadeDB versions:
This makes the boundary fairly sharp:
WHERE b:KNOWS fails
MATCH ...-[b:KNOWS]->... works
WHERE type(b) = 'KNOWS' works
So this looks like a wrong-result bug in ArcadeDB's handling of relationship type predicates over already bound relationship variables, not a general type-resolution failure.
Differential seed
This family surfaced in the skeleton differential run from:
RedisGraph__RedisGraph__2270__q002
Observed skeleton-run differential case:
MATCH (a)-[b]->(c)
WHERE b:KNOWS
RETURN b;
Observed results there:
- Neo4j:
2 rows
- ArcadeDB:
0 rows
The minimized count-based repro above shows the core issue more directly.
ArcadeDB version
Observed on Docker images:
arcadedata/arcadedb:26.3.2arcadedata/arcadedb:26.4.1-SNAPSHOTarcadedata/arcadedb:26.4.2Environment
/api/v1/command/arcadelanguage: opencypherserializer: studioneo4j:latestDescribe the bug
ArcadeDB may evaluate a relationship type predicate such as
b:KNOWSas false even afterbhas already been bound by a relationship pattern.In the minimized repro below:
MATCH (a)-[b]->(c)clearly binds two relationshipsKNOWSNeo4j therefore returns both rows.
ArcadeDB instead returns zero rows.
This does not look like a general relationship-type problem:
MATCH (a)-[b:KNOWS]->(c)worksWHERE type(b) = 'KNOWS'also worksSo the failure appears specific to the
relVar:TYPEpredicate form after the relationship variable is already bound.To Reproduce
Setup:
Query:
Expected behavior
Neo4j returns:
ArcadeDB should return the same result.
Actual behavior
Observed ArcadeDB result on all tested versions:
So the bound relationship variable
bis treated as if it were not of typeKNOWS, even though both matched relationships areKNOWS.Control cases
If the relationship type is expressed directly in the pattern, ArcadeDB behaves correctly:
Observed result on Neo4j and all tested ArcadeDB versions:
If the same check is expressed using
type(b), ArcadeDB also behaves correctly:Observed result on Neo4j and all tested ArcadeDB versions:
This makes the boundary fairly sharp:
WHERE b:KNOWSfailsMATCH ...-[b:KNOWS]->...worksWHERE type(b) = 'KNOWS'worksSo this looks like a wrong-result bug in ArcadeDB's handling of relationship type predicates over already bound relationship variables, not a general type-resolution failure.
Differential seed
This family surfaced in the skeleton differential run from:
RedisGraph__RedisGraph__2270__q002Observed skeleton-run differential case:
Observed results there:
2rows0rowsThe minimized count-based repro above shows the core issue more directly.