Inconsistent results when adding an inconsequential `FOREACH` clause

[DominicWuest]

I found a discrepancy when running two semantically equivalent queries against an empty database:

---

1:

FOREACH ( n0 IN [0, 0] | MERGE ()<-[x:A]-() DELETE x ) MERGE (:A)
-
RETURN COUNT { () } AS n

Produces:

╒═══╕
│"n"│
╞═══╡
│3  │
└───┘

---

2:

FOREACH ( n0 IN [0, 0] | MERGE ()<-[x:A]-() DELETE x ) MERGE (:A) FOREACH (y IN [null] | SET y += {n2: 0} )
-
RETURN COUNT { () } AS n

Produces:

╒═══╕
│"n"│
╞═══╡
│5  │
└───┘

---

I believe the queries mentioned above are semantically equivalent and thus their result should be the same. The only difference between them is the inclusion of the last FOREACH clause. But as it only adds a property to a null entity, it shouldn't have any effect on the query's outcome.

I encountered this issue when testing queries against the Neo4j 5.6.0 enterprise version in a Docker container running alpine v.3.

Steps to reproduce

Run the aforementioned, semantically equivalent, queries against an empty database and observe that their results differ.

Expected behavior

The queries should result in the same behavior

Actual behavior

The first query returns 3, whereas the second query returns 5.

[InverseFalcon]

This appears to be a SLOTTED runtime bug.

When I execute the first query with PIPELINED runtime, 5 nodes are created, which is correct.

When I execute the first query forcing SLOTTED runtime, 3 nodes are created, which is incorrect. (we also get the incorrect result with the second query).

An EXPLAIN of both plans shows that the first query will execute using PIPELINED runtime by default, and the second query will execute using SLOTTED runtime by default (we cannot force the second query to use PIPELINED runtime, there are some operations for which PIPELINED runtime cannot be used, and this query is such a case). This runtime difference (bug) appears to be the cause of the behavior change.

[DominicWuest]

I just noticed that this bug no longer triggers already since version 5.9.0! Is it safe to close this issue as completed?

[sherfert]

I just noticed that this bug no longer triggers already since version 5.9.0! Is it safe to close this issue as completed?

Yes.