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
• 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 allReduce(...) incorrectly and return false even when every iteration satisfies the predicate.

In the minimized repro below, the accumulator takes values 1, 3, and 6.
All of those values satisfy x > 0 for the corresponding element, so the result should be true.
Neo4j returns true.
ArcadeDB returns false.

To Reproduce

Query:

RETURN allReduce(acc = 0, x IN [1, 2, 3] | acc + x, x > 0) AS result;

Expected behavior
Observed Neo4j result:

true

Actual behavior
Observed ArcadeDB result:

false

Control cases

Plain reduce(...) works correctly on both engines:

RETURN reduce(acc = 0, x IN [1, 2, 3] | acc + x) AS total;

Observed result:

6

Plain all(...) also works correctly on both engines:

RETURN all(x IN [1, 2, 3] WHERE x > 0) AS result;

Observed result:

true

So the issue is not a general reduce(...) problem, and it is not a general all(...) problem. The failure is specific to allReduce(...).

Additional controls

If the predicate is actually false for every iteration, both engines return false:

RETURN allReduce(acc = 0, x IN [1, 2, 3] | acc + x, x > 10) AS result;

Observed result on both engines:

false

If the list is empty, Neo4j returns vacuous truth, but ArcadeDB still returns false:

RETURN allReduce(acc = 0, x IN [] | acc + x, x > 0) AS result;

Observed results:

• Neo4j: true
• ArcadeDB: false

This suggests ArcadeDB may be using the wrong default truth value for allReduce(...), or otherwise evaluating the construct against the wrong state.

If the predicate depends on the accumulator instead, both engines can still agree:

RETURN allReduce(acc = 0, x IN [1, 2, 3] | acc + x, acc >= 0) AS result;

Observed result on both engines:

true

So the failure is not that allReduce(...) is completely unsupported. It appears to mis-evaluate at least some valid predicate forms.