ArcadeDB version

Observed on Docker images:

• arcadedata/arcadedb:latest
• arcadedata/arcadedb:26.4.1-SNAPSHOT

Environment

• Docker on Windows host
• ArcadeDB queried through the HTTP API: /api/v1/command/arcade
• Requests sent in the same shape used by ArcadeDB Studio:
  • language: opencypher
  • serializer: studio

Describe the bug

EXISTS { MATCH ... } subqueries may incorrectly return false for some relationship types even when the same pattern clearly matches.

In the minimized repro below, Alice has one outgoing WORKS_WITH relationship.
Neo4j reports worksWith = true for Alice.
ArcadeDB reports worksWith = false for every row.

The equivalent direct pattern predicate outside the subquery works correctly, which suggests the issue is specifically tied to EXISTS { MATCH ... }.

To Reproduce

Setup

CREATE (:Person {name:'Alice'}),
       (:Person {name:'Bob'}),
       (:Person {name:'Charlie'}),
       (:Person {name:'David'});

MATCH (a:Person {name:'Alice'}), (b:Person {name:'Bob'})
CREATE (a)-[:WORKS_WITH]->(b);

MATCH (c:Person {name:'Charlie'}), (d:Person {name:'David'})
CREATE (c)-[:KNOWS]->(d);

Query

MATCH (p:Person)
RETURN p.name AS person,
       EXISTS { MATCH (p)-[:WORKS_WITH]->(:Person) } AS worksWith
ORDER BY person;

Expected behavior

Only Alice should satisfy the WORKS_WITH existence test:

Alice   true
Bob     false
Charlie false
David   false

Actual behavior

ArcadeDB returns:

Alice   false
Bob     false
Charlie false
David   false

So the EXISTS subquery misses a relationship that is definitely present.

Control cases

Control 1, the equivalent direct pattern predicate behaves correctly on both engines:

MATCH (p:Person)
WHERE (p)-[:WORKS_WITH]->(:Person)
RETURN p.name AS person
ORDER BY person;

Observed result:

Alice

Control 2, EXISTS { MATCH ... } does work for a simpler relationship type in the same dataset:

MATCH (p:Person)
RETURN p.name AS person,
       EXISTS { MATCH (p)-[:KNOWS]->(:Person) } AS knowsRel
ORDER BY person;

Observed result on both Neo4j and ArcadeDB:

Alice   false
Bob     false
Charlie true
David   false

This suggests the issue is not that all EXISTS { MATCH ... } subqueries fail, but that some relationship types can be mishandled inside them.