Problem
get_handle_mut::<PgConnectionHandle> hands out a &'static mut reference from a tokio blocking-pool thread, while the main thread can simultaneously call take_handle on the very same handle — js_pg_client_end does exactly that.
Why it matters
This is an aliasing hazard: two threads can hold a live mutable reference (one via get_handle_mut, one via take_handle on the main thread) to the same underlying connection handle at the same time, which is undefined behavior in Rust regardless of whether a concrete crash has been observed. This is a pre-existing issue in the legacy spawn_blocking-based path, independent of the turnloop migration.
What would fix it
Whatever synchronization already protects other handle-table accesses (a lock, or restructuring so a handle in active use on a blocking-pool thread cannot be concurrently taken from the main thread) needs to cover PgConnectionHandle too. At minimum, take_handle should not be able to race a live get_handle_mut borrow on the same handle.
Problem
get_handle_mut::<PgConnectionHandle>hands out a&'static mutreference from a tokio blocking-pool thread, while the main thread can simultaneously calltake_handleon the very same handle —js_pg_client_enddoes exactly that.Why it matters
This is an aliasing hazard: two threads can hold a live mutable reference (one via
get_handle_mut, one viatake_handleon the main thread) to the same underlying connection handle at the same time, which is undefined behavior in Rust regardless of whether a concrete crash has been observed. This is a pre-existing issue in the legacyspawn_blocking-based path, independent of the turnloop migration.What would fix it
Whatever synchronization already protects other handle-table accesses (a lock, or restructuring so a handle in active use on a blocking-pool thread cannot be concurrently taken from the main thread) needs to cover
PgConnectionHandletoo. At minimum,take_handleshould not be able to race a liveget_handle_mutborrow on the same handle.