Closed DominicWuest closed 1 year ago
This appears to be a PIPELINED runtime bug.
If I force SLOTTED runtime instead by prefixing with CYPHER runtime=SLOTTED
then the query is able to run.
Thanks @DominicWuest! I've created a ticket in our internal bug tracker for further investigation (link).
@DominicWuest We have found and fixed the issue and the fix will be part of 5.9 I could not reproduce the issue on 4.4.
Hello @sherfert! I hope I'm not bothering you, but would it be possible to get a quick explanation of what caused this bug?
Sure. This was a bug in the planner. Before the bugfix, the query was planned like this:
+-----------------------------------+----+---------------------------------------------------+----------------+---------------------+
| Operator | Id | Details | Estimated Rows | Pipeline |
+-----------------------------------+----+---------------------------------------------------+----------------+---------------------+
| +ProduceResults | 0 | `0` | 0 | |
| | +----+---------------------------------------------------+----------------+ |
| +Projection | 1 | $autoint_0 AS `0` | 0 | |
| | +----+---------------------------------------------------+----------------+ |
| +Expand(Into) | 2 | (a)-[r:C]->(b) | 0 | |
| | +----+---------------------------------------------------+----------------+ |
| +Filter | 3 | r:B | 0 | |
| | +----+---------------------------------------------------+----------------+ |
| +Apply | 4 | | 0 | |
| |\ +----+---------------------------------------------------+----------------+ |
| | +Distinct | 5 | r, a, b | 0 | |
| | | +----+---------------------------------------------------+----------------+ |
| | +Union | 6 | | 0 | Fused in Pipeline 6 |
| | |\ +----+---------------------------------------------------+----------------+---------------------+
| | | +Filter | 7 | not b:E | 0 | |
| | | | +----+---------------------------------------------------+----------------+ |
| | | +DirectedAllRelationshipsScan | 8 | (a)-[r]->(b) | 3 | Fused in Pipeline 5 |
| | | +----+---------------------------------------------------+----------------+---------------------+
| | +Filter | 9 | not b:D | 0 | |
| | | +----+---------------------------------------------------+----------------+ |
| | +DirectedAllRelationshipsScan | 10 | (a)-[r]->(b) | 3 | Fused in Pipeline 4 |
| | +----+---------------------------------------------------+----------------+---------------------+
| +Eager | 11 | | 1 | In Pipeline 3 |
| | +----+---------------------------------------------------+----------------+---------------------+
| +SubqueryForeach | 12 | | 1 | |
| |\ +----+---------------------------------------------------+----------------+ |
| | +Create | 13 | (anon_0), (anon_2), (anon_0)-[anon_1:A]->(anon_2) | 1 | Fused in Pipeline 1 |
| | +----+---------------------------------------------------+----------------+---------------------+
| +EmptyRow | 15 | | 1 | In Pipeline 0 |
+-----------------------------------+----+---------------------------------------------------+----------------+---------------------+
Note how the Expand(Into)
with Id 2 overwrites the existing column r
. That is not allowed.
It now gets planned as
+---------------------------------+----+---------------------------------------------------+----------------+---------------------+
| Operator | Id | Details | Estimated Rows | Pipeline |
+---------------------------------+----+---------------------------------------------------+----------------+---------------------+
| +ProduceResults | 0 | `0` | 0 | |
| | +----+---------------------------------------------------+----------------+ |
| +Projection | 1 | $autoint_0 AS `0` | 0 | |
| | +----+---------------------------------------------------+----------------+ |
| +Filter | 2 | anon_4:B AND (NOT anon_5:D OR NOT anon_5:E) | 0 | |
| | +----+---------------------------------------------------+----------------+ |
| +Apply | 3 | | 3 | |
| |\ +----+---------------------------------------------------+----------------+ |
| | +DirectedRelationshipTypeScan | 4 | (anon_3)-[anon_4:C]->(anon_5) | 3 | Fused in Pipeline 4 |
| | +----+---------------------------------------------------+----------------+---------------------+
| +Eager | 5 | | 1 | In Pipeline 3 |
| | +----+---------------------------------------------------+----------------+---------------------+
| +SubqueryForeach | 6 | | 1 | |
| |\ +----+---------------------------------------------------+----------------+ |
| | +Create | 7 | (anon_0), (anon_2), (anon_0)-[anon_1:A]->(anon_2) | 1 | Fused in Pipeline 1 |
| | +----+---------------------------------------------------+----------------+---------------------+
| +EmptyRow | 9 | | 1 | In Pipeline 0 |
+---------------------------------+----+---------------------------------------------------+----------------+---------------------+
which is a valid plan.
Awesome, thank you for the explanation!
When running the following query:
I encountered the following error:
I believe the query mentioned above is semantically and syntactically correct and thus no error should be thrown here.
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 following queries and observe it throws an error:
Expected behavior
The query should run successfully
Actual behavior
The query fails with the error message
Neo4jError: Neo.DatabaseError.Statement.ExecutionFailed (Cannot invoke "org.neo4j.internal.kernel.api.RelationshipDataAccessor.type()" because "this.v3_relationships" is null)