`all()` over pattern-comprehension list returns wrong result on larger graphs

[shulei5831sl]

ArcadeDB version

Observed on local Docker image:

docker inspect arcadedb -> arcadedata/arcadedb:latest
docker exec arcadedb find /home/arcadedb/lib -name 'arcadedb-server-*.jar'
/home/arcadedb/lib/arcadedb-server-26.7.2-SNAPSHOT.jar

ArcadeDB version: 26.7.2-SNAPSHOT
Build: f88429c1

Endpoint:
http://127.0.0.1:2480/api/v1/command/test

Environment

• Host OS: Linux

• Deployment: Docker

• Query interface: HTTP /api/v1/command/test

• Query language: Cypher

• Differential comparison targets:

  • Neo4j Community 2026.05.0
  • Memgraph 3.11.0

Description

ArcadeDB returns the wrong result for all() when the input list is produced by a pattern comprehension.

The failing query collects each active user's friends' active values through a pattern comprehension, then flags users whose friend list is non-empty and contains only inactive friends:

MATCH (u:User {active: true})
WITH u, [(u)-[:FRIEND]->(f:User) | f.active] AS actives
WHERE size(actives) > 0 AND all(a IN actives WHERE a = false)
SET u.flagged = true;

On a small 6-node graph, ArcadeDB returns the correct result. On a deterministic 35-node graph generated with seed 42, the same query returns the wrong result.

The equivalent formulation using explicit MATCH + collect() works correctly on the same 35-node graph, which isolates the failure to the pattern-comprehension list used by all().

Neo4j and Memgraph return the expected result.

To reproduce

Run from a clean database.

1. Small graph baseline — correct on ArcadeDB

MATCH (n) DETACH DELETE n;

CREATE
  (u1:User {id:1, active:true}),
  (u2:User {id:2, active:true}),
  (u3:User {id:3, active:true}),
  (u4:User {id:4, active:false}),
  (u5:User {id:5, active:false}),
  (u6:User {id:6, active:false}),
  (u1)-[:FRIEND]->(u4),
  (u1)-[:FRIEND]->(u5),
  (u2)-[:FRIEND]->(u4),
  (u2)-[:FRIEND]->(u1),
  (u3)-[:FRIEND]->(u5),
  (u3)-[:FRIEND]->(u6);

Expected reasoning:

u1 friends: [false, false] => all inactive => flag
u2 friends: [false, true]  => has active   => do not flag
u3 friends: [false, false] => all inactive => flag

Query:

MATCH (u:User {active: true})
WITH u, [(u)-[:FRIEND]->(f:User) | f.active] AS actives
WHERE size(actives) > 0 AND all(a IN actives WHERE a = false)
SET u.flagged = true;

MATCH (u:User)
WHERE u.flagged = true
RETURN u.id AS id
ORDER BY id;

ArcadeDB result:

id = 1
id = 3

This is correct.

2. Larger graph — wrong result on ArcadeDB

The attached Python reproducer builds a deterministic 35-node graph using seed 42.

The graph contains:

20 active User nodes
15 inactive User nodes
random FRIEND edges generated from seed 42

Run the same query:

MATCH (u:User {active: true})
WITH u, [(u)-[:FRIEND]->(f:User) | f.active] AS actives
WHERE size(actives) > 0 AND all(a IN actives WHERE a = false)
SET u.flagged = true;

MATCH (u:User)
WHERE u.flagged = true
RETURN count(*) AS cnt;

Expected behavior

On the 35-node graph generated with seed 42, exactly 2 active users have a non-empty friend list where all friends are inactive.

Expected result:

cnt = 2

Neo4j 2026.05.0 returns:

cnt = 2

Memgraph 3.11.0 returns:

cnt = 2

Actual behavior

ArcadeDB returns:

cnt = 0

No error or warning is reported.

Read-only diagnostic query

This query exposes the pattern-comprehension list and all() result per user without performing writes:

MATCH (u:User {active: true})
WITH u, [(u)-[:FRIEND]->(f:User) | f.active] AS actives
RETURN
  u.id AS id,
  actives,
  size(actives) AS sz,
  all(a IN actives WHERE a = false) AS all_inactive
ORDER BY id;

On the same 35-node graph, Neo4j and Memgraph identify 2 users with:

sz > 0
all_inactive = true

ArcadeDB returns all_inactive = false for those same expected users.

Control: explicit MATCH + collect() works on ArcadeDB

Using explicit MATCH + collect() instead of pattern comprehension returns the correct result on the same 35-node graph:

MATCH (u:User {active: true})-[:FRIEND]->(f:User)
WITH u, collect(f.active) AS actives
WHERE size(actives) > 0 AND all(a IN actives WHERE a = false)
RETURN count(DISTINCT u) AS cnt;

ArcadeDB result:

cnt = 2

So all() can evaluate correctly when the list is produced by collect(). The wrong result appears when the list is produced by pattern comprehension.

Cross-engine comparison

35-node graph, seed 42:

Engine	Pattern comprehension + all()
Neo4j 2026.05.0	cnt = 2
Memgraph 3.11.0	cnt = 2
ArcadeDB 26.7.2-SNAPSHOT	cnt = 0

Same graph, ArcadeDB only:

Query form	ArcadeDB result
pattern comprehension + all()	cnt = 0
explicit MATCH + collect() + all()	cnt = 2

Summary

Query shape	6-node graph	35-node graph
pattern comprehension + all()	correct	wrong
explicit MATCH + collect() + all()	correct	correct

Why this looks like a bug

The query is semantically valid and returns the expected result on Neo4j and Memgraph.

ArcadeDB also returns the correct result on a small graph, and the equivalent MATCH + collect() formulation works correctly on the same 35-node graph.

The failure appears specific to the interaction between pattern-comprehension list evaluation and all() on the larger graph. I am not claiming a fixed threshold here; the attached deterministic reproducer is intended to make the failing graph state exact.

[lvca]

Thanks for the detailed report and the differential comparison. I've investigated this thoroughly but cannot reproduce the wrong result on the exact build you're running (f88429c1) or on current main.

What I tried:

• Ran the exact query (both the SET/count(*) form and the read-only diagnostic) via the HTTP /api/v1/command endpoint and the embedded engine.
• Rebuilt "20 active / 15 inactive, random FRIEND edges, seed 42, exactly 2 qualifying users" across every common generation scheme (pairwise probability, random.sample, randint, symmetric/bidirectional edges), created both via Cypher CREATE (as you did) and the Java API.
• Fuzzed 1000+ additional graphs (6-40 nodes, varied density).

In every case ArcadeDB returns the same result as collect() and as Neo4j/Memgraph (cnt = 2). The pattern-comprehension list comes back byte-for-byte identical to the collect() list, including the Boolean element type, so all(a IN actives WHERE a = false) agrees.

The issue body mentions "the attached Python reproducer", but no script or data file is actually attached to the issue - so I can't load your precise seed-42 graph, and the bug is clearly data-specific. Could you please attach:

1. The Python reproducer (or the raw graph as an edge-list dump, e.g. MATCH (u:User)-[:FRIEND]->(f:User) RETURN u.id AS u, collect(f.id) AS friends ORDER BY u), and
2. Any non-default settings on your server (contents of config/ / ARCADEDB_* env vars / -Darcadedb.* flags), e.g. parallelism or bucket-count overrides.

With the exact graph I can pin down the triggering state immediately.

[shulei5831sl]

I found a smaller deterministic trigger on the latest build:

• ArcadeDB 26.7.2-SNAPSHOT
• build 7ff3b63d/1783560823997/main
• Docker image: today's arcadedata/arcadedb:latest

This appears to hit the same area as this issue: all() over a list produced by pattern comprehension.

I would not claim the exact internal root cause, but the minimal deterministic trigger seems to be: a parenthesized predicate inside all() when the iterated list comes from pattern comprehension.

Minimal repro

MATCH (n) DETACH DELETE n;

CREATE
  (a:U {id:1, v:true}),
  (b:U {id:2, v:false}),
  (c:U {id:3, v:false}),
  (d:U {id:4, v:true}),
  (a)-[:E]->(b),
  (a)-[:E]->(c),
  (d)-[:E]->(b);

Both user 1 and user 4 have only inactive outgoing :E neighbors:

• user 1: [false, false]
• user 4: [false]

So both should be flagged.

MATCH (u:U {v:true})
WITH u, [(u)-[:E]->(f:U) | f.v] AS actives
WHERE size(actives) > 0 AND all(a IN actives WHERE (a=false))
SET u.flagged = true;

MATCH (u:U)
WHERE u.flagged = true
RETURN u.id AS id
ORDER BY id;

Expected

[1, 4]

Actual

[]

Comparison matrix

Predicate	Result	Correct?
all(a IN actives WHERE a=false)	[1, 4]	✅
all(a IN actives WHERE (a=false))	[]	❌
all(a IN actives WHERE (a = false))	[]	❌
all(a IN actives WHERE ((a=false)))	[]	❌
all(a IN actives WHERE a<>true)	[1, 4]	✅
NOT any(a IN actives WHERE a=true)	[1, 4]	✅
none(a IN actives WHERE a=true)	[1, 4]	✅

Controls

The same parenthesized predicate works correctly on a literal list:

RETURN all(a IN [false, false] WHERE (a=false)) AS ok;

Expected and actual:

true

The non-parenthesized predicate also works correctly with the same pattern-comprehension input:

MATCH (u:U {v:true})
WITH u, [(u)-[:E]->(f:U) | f.v] AS actives
WHERE size(actives) > 0 AND all(a IN actives WHERE a=false)
SET u.flagged = true;

MATCH (u:U)
WHERE u.flagged = true
RETURN u.id AS id
ORDER BY id;

Expected and actual:

[1, 4]

Key observations

1. Parenthesizing the equality predicate changes the result.
2. The failure only appears when the input list comes from pattern comprehension.
3. Equivalent predicates such as a<>true, NOT any(...), and none(...) return the correct result.
4. size(actives) > 0 rules out empty-list / vacuous-truth behavior.
5. The repro is deterministic and does not require concurrency.

This may help reduce the original larger-graph reproducer to a 4-node / 3-edge deterministic case.

[shulei5831sl]

Thanks for adding the regression test.

I think the current test still misses the actual trigger I am seeing. The issue is not only all() over a pattern-comprehension list, but specifically the parenthesized predicate inside all().

These two forms should be semantically identical:

all(a IN actives WHERE a = false)    -- passes
all(a IN actives WHERE (a = false))  -- fails

[lvca]

Thanks for the precise follow-up, you nailed it. This was indeed a separate bug specific to a parenthesized predicate inside a list quantifier (all/any/none/single) when used in a WHERE clause.

What happened: WHERE all(a IN actives WHERE (a = false)) was parsed incorrectly. The parser picked up the inner parentheses (a = false) and dropped the surrounding all(...), so the filter ended up evaluating just a = false against a variable that only exists inside the quantifier. The result was that every row got filtered out (hence cnt = 0 / empty result). Without the parentheses the query took a different path and worked, which is exactly the discrepancy you saw.

Fixed on main: parentheses are now only treated as a grouping around the whole predicate when they actually wrap the whole predicate, so the quantifier is preserved. Both forms now return the same result:

all(a IN actives WHERE a = false)     // works
all(a IN actives WHERE (a = false))   // now works too, same result

Added regression tests covering the parenthesized form (single and nested parentheses). It will be in the next release. Thanks again for the clear reproducer!