[P1]SessionPool move constructor does not transfer idle sessions and can leave dangling pool references #147

Please check the FAQ documentation before raising an issue

Describe the bug (required)
The current SessionPool(SessionPool&&) moves only the configuration and the underlying ConnectionPool; it does not move idleSessions_. After the move, the source object still owns the existing Session wrappers while the destination's idle-session list is empty. Even if the destination pool was successfully initialized before the move, its first request returns No idle session..

A Session in the source pool stores a raw pointer to the underlying ConnectionPool. The destination owns the moved unique_ptr<ConnectionPool>. If the destination is destroyed first, the underlying pool is freed. When the source is destroyed later, its idle Session may return a connection through that dangling pointer, creating a use-after-free risk.

Your Environments (required)

• OS: ubuntu
• Commit id : 7cbe032（master ，2026-10-14）

How To Reproduce(required)

1. Start a reachable Nebula Graph server, configure a SessionPool with maxSize_ = 1, and successfully call init().
2. Move-construct another pool from the initialized pool.
3. Call execute("YIELD 1") on the destination object.
4. Arrange for the destination to be destroyed before the source (for example, put the destination in an inner scope).

nebula::SessionPool source(config);
ASSERT_TRUE(source.init());
{
  nebula::SessionPool moved(std::move(source));
  auto resp = moved.execute("YIELD 1");
  // Current behavior: resp.errorMsg is "No idle session."
}
// If the source still owns idle Sessions, its destructor may access
// the already-freed ConnectionPool here.

Expected behavior

After the move, the destination should own the original idle sessions and the query should succeed. The source should be left in a safe moved-from state. Neither destruction order should access a freed underlying pool.

Actual behavior

In the targeted reproduction, the destination returned No idle session.. The destruction-order risk follows from the raw pool pointer held by idle Session objects and the ownership transfer described above; the use-after-free has not been independently captured with ASan.

Additional context
A SessionPool becomes unusable after moving it once initialized. Under a particular destruction order, the program may exhibit undefined behavior or crash.