Neo4j PARALLEL runtime query returns different result

I'm testing the new Neo4j PARALLEL runtime and am unable to pass my tests because my queries return different results (different elements order) compared to SLOTTED or PIPELINED. Do I need to somehow refine these queries so that they work properly on PARALLEL runtime? Do you have any docs on this? Or, are these refinements unnecessary, and the queries should return exactly the same result as on SLOTTED or PIPELINED?

Also, there is a limitation It is not possible to use the parallel runtime if a change has been made to the state of a transaction. https://neo4j.com/docs/cypher-manual/current/planning-and-tuning/runtimes/reference/

Unfortunately, I have many scenarios where I currently use apoc.cypher.mapParallel2 to read data in the same transaction where I'm updating it. I would like to transition to the PARALLEL runtime, but I am unable to do so due to this limitation. Are you planning to overcome this limitation in the future?

Solution

Due the the Parallel nature of Neo4j these situations stem as reasons for what you experienced.

Results may not be deterministic, as different threads may finish at different times - use the ORDER BY clause
PARALLEL runtime does not support updating queries, such as those using the CREATE, MERGE, SET, DELETE, or REMOVE - updating the graph in parallel may cause conflicts or inconsistencies to use the same to read ,use :begin and :commit commands in Cypher Shell to control the transactions or another runtime, such as SLOTTED or PIPELINED, for the write queries.
Also it does not support reading data that has been modified in the same transaction, as this may cause concurrency issues or stale reads aka you cannot use the apoc.cypher.mapParallel2 procedure to read data that you have updated in the same transaction - use another procedure, such as apoc.cypher.doIt, or split transaction into two parts.

For situational restrictions so mentioned , I doubt if they have plans to update.