Closed mindaugasrukas closed 3 weeks ago
To add more context:
We don't see any issues running that query on the Aura query UI.
Attached query profile SVG:
Thank you for raising the issue with such detail @mindaugasrukas. I will get back to you once we've investigated on our end.
Quick update for you:
We assume the issue is related to the length of the path of a result. We don't see this issue on small paths.
You're correct here, in hydrator.path we make a slice with its length dependent on the path, if this is too large (such as make([]int, math.MaxInt64)
) the same error occurs, it's essentially an out-of-memory error.
Edit: I noticed your upper bounds are quite large (number of hops) at 500, we normally say anything over 10 is starting to become quite high. The following support page is a good read and has an example for explaining the magnitude of increasing the upper bounds from 4 -> 14: https://support.neo4j.com/s/article/12667263111955-Specifying-Upper-Bounds-On-Relationship-Pattern-Matching-in-Cypher-Queries.
Thanks. Let me know how can I help to debug the issue. Some additional notes: we have multiple disconnected graphs in the database. When we hit smaller graphs, we have no issues. When we hit bigger ones, almost always, we get panicked. It seems like there is no relation with the result size but the size of the possible max length of the graph. Does that ring any bells?
@StephenCathcart I created a reproducible example: https://github.com/StencilFrame/neo4j-go-driver-panic
@StephenCathcart any updates?
This issue is blocking our future development. Could you please provide us with an update on the status of this issue? If there is something we need to adjust on our end, we would appreciate guidance on how to proceed. Given that this matter affects our development process, we would like to know whether we should wait for a resolution or explore alternative solutions.
Hi @mindaugasrukas, thank you for providing the reproducible example, we were struggling to reproduce this on our end it's a massive help. We're just discussing the best way to tackle this issue. At first, I assumed that we were trying to create a slice too large (due to the size of the hops/path from your query) which would cause the error, however, it looks like we are trying to create a slice with a negative size which is unusual and a possible bug in our hydrator/unpacker. I will let you know as soon as we have a fix for this.
@mindaugasrukas we've made some progress on the panic, it looks like a bug in the hydrator when figuring out the length of the path, it's intermittent as the panic only happens if the size of the path falls between a particular range (for example 128-255). We're just testing the fix now, it will be included in the next release scheduled for the end of the month, but I'll see if we can get a patch release out earlier, I'll keep you posted.
Thank you for your prompt response. I appreciate it.
Hi @mindaugasrukas, a patch has been released (v5.23.1) which includes a fix to the above issue. Please let me know if this fixes the problem you're seeing, thanks!
Yes, that solved our issue. Thanks, @StephenCathcart.
We are getting panics with the message:
runtime error: makeslice: len out of range
. More details below.Neo4j Version: 5 (neo4j Aura) Neo4j Mode: Single instance
Driver version: Go driver v5.22.0 Operating System: alpine:3.20 (Docker on K8s)
Steps to reproduce
Unknown yet
We assume the issue is related to the length of the path of a result. We don't see this issue on small paths.
CYPHER query example we execute:
Explanation of the query:
path = shortestPath(...)
is probably not needed. This is just to make it easier to parse the results later. We could returnRETURN p1, p, p2
, but that makes it complicated to build the full end-to-end path.So far, we observe that if a final path is somewhere more than 100 nodes long (not sure exactly), we get a panic. The largest of our paths might be around 1000 nodes long.
We have this index:
Expected behavior
no error
Actual behavior
The client failed to run the query with a panic
runtime error: makeslice: len out of range
. The stacktrace is attached below.Stack trace (I removed unrelated internal library names):