Running on 4.4.2 enterprise version, I'm facing a very strange problem. I'm sorry that I can't expose the cypher or sample data here. Before digging deeper, maybe someone can just tell if this can be properly explained or if it looks like bug not only to me.
We are running a quite complex cypher with almost 80 lines but at the end, all is reduced to just 2 properties and the correct result of 3 rows.
After deeper investigation the cause are these red marked parts of a pattern comprehension somewhere in the middle of our cypher. When I remove these parts, the result shows the expected 3 rows and come in correct order, when I let them in, I get 4 rows with 1 duplicate and wrong order. ... but why?
And another strange effect, when I aggregate lastrequest like
max(lastrequest) as lastrequest in the last with-clause, I get 3 rows with correct order again....
so both identical lastrequest values where not properly aggregated and not properly ordered... but ONLY when adding a LIMIT 15 at the end? I really start loosing confidence ..
This looks indeed odd. It is, however, hard to assess without knowing the query plan. So, if you could provide that for the problematic cases, we could investigate this further.
As you seem to be using Neo4j Enterprise, it might make things easier if you (in confidence) contact Neo4j Support to disclose more information. Is that an option?
Hi Arne, plans attached. I could find a line that causes the effect. In lines 33 and 35 and use pattern comprehensions to calculate a message count and unread message count. Line 35 is the problem. When I use size() or tail() or just the output of the pattern comprehension, the order is wrong because those values in lastrequest seems not be that what is shown. That's why order is wrong and they don't get grouped later (i cutted out that later grouping part to see clearer results of that part). The attached plan.png is for that first result.
My workaround for now is to transform lastRequest to toString(lastRequest) to force values that look identical to be truly identical - then grouping and ordering works correctly in the end.