Bug: selectLive().next() can deadlock due to incorrect locking in Rust JNI layer

[joaoseidel]

Describe the bug

Calling LiveStream.next() after selectLive() can block forever (deadlock). The root cause is in the Rust JNI layer (live.rs), where the recv_mutex lock is held while blocking on receiving the next notification. If close() is called on another thread, or if the background stream thread interacts in certain timing, this can cause a deadlock because both sides try to acquire the same locks in opposite order. This deadlock can prevent closing the stream, drain JVM threads, or hang an application using surrealdb.java for live queries.

Steps to reproduce

1. Start a live query using selectLive() in Java.
2. Run a while true loop, call next() and leave it blocked waiting for a notification.
3. Try updating a record and see that the notification never comes

Expected behaviour

Calling next() should never block forever if close() is called, and closing a LiveStream should always cleanly awaken any waiting thread and terminate the blocking call.

SurrealDB version

3.0.5

SurrealDB Java SDK version

2.0.0

Contact Details

No response

Is there an existing issue for this?

• I have searched the existing issues

Code of Conduct (repository /surrealdb.java)

• I agree to follow this project's Code of Conduct