OpenCypher：When `UNWIND` follows a `WITH` that carries rows forward from a previous `MATCH`, ArcadeDB may duplicate every expanded row by the size of the upstream row set.

[Silence6666668]

ArcadeDB version

• ArcadeDB version：26.4.1-SNAPSHOT
  Observed on Docker image:
• arcadedata/arcadedb:latest

Environment

• Docker on Windows host
• ArcadeDB queried through the HTTP API: /api/v1/command/arcade
• Neo4j and Memgraph used as reference engines for comparison

Describe the bug

When UNWIND follows a WITH that carries rows forward from a previous MATCH, ArcadeDB may duplicate every expanded row by the size of the upstream row set.

In the minimized repro below, there are two input rows (Alice and Charlie).
Each of them is unwound across range(1, 3), so the expected result is 2 * 3 = 6 rows.

Neo4j and Memgraph both return 6 rows.
ArcadeDB returns 12 rows, with every logical row duplicated once.

To Reproduce

Setup

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

Query

MATCH (p:Person)
WITH p.name AS personName
WHERE personName <> 'Bob'
UNWIND range(1, 3) AS i
RETURN personName, i
ORDER BY personName, i;

Expected behavior

Two surviving input rows (Alice, Charlie) expanded by range(1, 3) should produce:

Alice, 1
Alice, 2
Alice, 3
Charlie, 1
Charlie, 2
Charlie, 3

That is 6 rows total.

Actual behavior

ArcadeDB returns 12 rows:

Alice, 1
Alice, 1
Alice, 2
Alice, 2
Alice, 3
Alice, 3
Charlie, 1
Charlie, 1
Charlie, 2
Charlie, 2
Charlie, 3
Charlie, 3

Each logical row is duplicated.

Control cases

Control 1, when the upstream MATCH produces only one row, the duplication disappears:

MATCH (p:Person {name: 'Alice'})
WITH p.name AS personName
UNWIND range(1, 3) AS i
RETURN personName, i
ORDER BY i;

Observed result on all engines:

Alice, 1
Alice, 2
Alice, 3

Control 2, without UNWIND, ArcadeDB also behaves correctly:

MATCH (p:Person)
WITH p.name AS personName
WHERE personName <> 'Bob'
RETURN personName
ORDER BY personName;

Observed result on all engines:

Alice
Charlie

This suggests the issue is specifically tied to UNWIND after WITH, not to the initial MATCH or the filter itself.

[lvca]

The issue cannot be reproduced on the current main branch. I believe the bug was already fixed by previous commits.

1. ca3dcb7 (March 23) - Changed shouldUseOptimizer() to allow queries with WITH/UNWIND to use the optimizer (previously, WITH caused immediate fallback to the non-optimized path)
2. 60257e1 (March 30) - Fixed buildExecutionStepsWithOptimizer() to iterate through clausesInOrder instead of using fixed ordering. The commit message explicitly states: "Bug 1 - Clause ordering in optimizer path: buildExecutionStepsWithOptimizer() processed ALL UNWIND steps before ALL WITH steps, ignoring the actual query order."

[lvca]

Added a regression test and passes: 08a9e0e.

Is it possible your 26.4.1-SNAPSHOT wasn't updated to a recent version?