ArcadeDB version

Observed on latest Docker image:

docker pull arcadedata/arcadedb:latest
Pulled: 2026-07-08
Digest: sha256:77545aac242ce2bf202cd6e85d2a4be1eb816b8fd25af999b8e4155009bc1582

ArcadeDB version: 26.7.2-SNAPSHOT
Build: f88429c1

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

Environment

• Host OS: Linux 5.4.0-216-generic

• Deployment: Docker arcadedata/arcadedb:latest

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

• Query language: Cypher / OpenCypher

• Differential comparison target:

  • Neo4j 2026.05.0

Description

ArcadeDB returns wrong results when a COUNT {} block subquery is used inside the WHERE clause of a pattern comprehension.

The COUNT {} predicate should filter the rows produced by the pattern comprehension. Instead, ArcadeDB returns all rows, as if the WHERE COUNT { ... } condition were not applied.

This is not the same as the inline relationship-property filter issues. The failing query does not use an inline property filter. The issue appears specific to evaluating a block subquery predicate inside pattern-comprehension WHERE.

The same COUNT {} logic works correctly in a CALL subquery.

To reproduce

Run from a clean database.

1. Setup

MATCH (n) DETACH DELETE n;

CREATE
  (a:CB {name: 'a'}),
  (b:CB {name: 'b'}),
  (c:CB {name: 'c'}),
  (d:CB {name: 'd'}),
  (a)-[:E {w: 1}]->(b),
  (a)-[:E {w: 2}]->(c),
  (b)-[:E {w: 3}]->(d);

Graph structure:

a -> b
a -> c
b -> d

So among the two nodes reached from a:

b has 1 outgoing E edge
c has 0 outgoing E edges

2. Failing query: COUNT{} = 0

MATCH (a:CB {name: 'a'})
RETURN [
  (a)-[:E]->(b:CB)
  WHERE COUNT { MATCH (b)-[:E]->(:CB) } = 0
  | b.name
] AS names;

Expected behavior

The pattern comprehension iterates over b and c.

For each candidate:

b: COUNT { MATCH (b)-[:E]->(:CB) } = 1  => exclude for = 0
c: COUNT { MATCH (c)-[:E]->(:CB) } = 0  => include for = 0

Expected result:

names = ['c']

Neo4j 2026.05.0 returns:

['c']

Actual behavior

ArcadeDB returns both nodes:

names = ['c', 'b']   -- order may vary

The COUNT{} = 0 predicate does not filter out b.

Additional failing predicates

The same setup also fails with other COUNT {} comparisons.

MATCH (a:CB {name: 'a'})
RETURN [
  (a)-[:E]->(b:CB)
  WHERE COUNT { MATCH (b)-[:E]->(:CB) } = 1
  | b.name
] AS names;

Expected:

['b']

ArcadeDB:

['c', 'b']   -- order may vary

MATCH (a:CB {name: 'a'})
RETURN [
  (a)-[:E]->(b:CB)
  WHERE COUNT { MATCH (b)-[:E]->(:CB) } > 0
  | b.name
] AS names;

Expected:

['b']

ArcadeDB:

['c', 'b']   -- order may vary

Summary:

Control 1: ordinary PC WHERE filter works

A normal predicate using the pattern-comprehension variable works correctly:

MATCH (a:CB {name: 'a'})
RETURN [
  (a)-[:E]->(b:CB)
  WHERE b.name = 'c'
  | b.name
] AS names;

ArcadeDB result:

['c']

So the pattern-comprehension WHERE clause itself is not ignored in general.

Control 2: equivalent CALL subquery works

The same COUNT {} logic works correctly inside a CALL subquery:

MATCH (a:CB {name: 'a'})
CALL {
  WITH a
  MATCH (a)-[:E]->(b:CB)
  WHERE COUNT { MATCH (b)-[:E]->(:CB) } = 0
  RETURN b.name AS n
}
RETURN collect(n) AS names;

ArcadeDB result:

['c']

This confirms that ArcadeDB can evaluate the same COUNT {} predicate correctly outside pattern comprehension.

Control 3: explicit CALL result for all candidates

This query shows the expected per-candidate counts:

MATCH (a:CB {name: 'a'})
CALL {
  WITH a
  MATCH (a)-[:E]->(b:CB)
  RETURN b.name AS name, COUNT { MATCH (b)-[:E]->(:CB) } AS out_count
}
RETURN name, out_count
ORDER BY name;

Expected and ArcadeDB result:

name='b', out_count=1
name='c', out_count=0

So the count logic itself is correct when evaluated in a normal subquery context.

Cross-engine comparison

Failing query:

MATCH (a:CB {name: 'a'})
RETURN [
  (a)-[:E]->(b:CB)
  WHERE COUNT { MATCH (b)-[:E]->(:CB) } = 0
  | b.name
] AS names;

Summary

Why this looks like a bug

The pattern-comprehension WHERE clause works for ordinary predicates, and the same COUNT {} expression works in a CALL subquery.

The failure appears specific to COUNT {} block subqueries inside pattern-comprehension WHERE.

The observed behavior is consistent with the COUNT {} predicate being ignored or mis-evaluated inside the pattern-comprehension filter. I am avoiding a stronger root-cause claim here, because the result pattern does not uniquely prove whether this is a scope-capture bug or a predicate-lowering bug.