Panic / crash when query times out while using TableSessionPool

[KrishnajithUS]

Description

Hi, I'm using i iotdb client go v2.0.3-1 with a TableSessionPool to run queries. When a query times out (server error code 712), calling Close() on the session afterward — typically in a deferred cleanup — causes a nil pointer panic that crashes the entire application instead of returning a handleable error.

What I Expected
When a query times out, I expected session.Close() to safely release the session back to the pool or clean up gracefully, and for my code to continue handling the timeout error normally.

What Actually Happened
After receiving the timeout error from ExecuteQueryStatement, the deferred session.Close() call triggers a nil pointer dereference panic that takes down the entire service.

Code That Triggers the Issue

gosession, err := params.TableSessionPool.GetSession()
if err != nil {
    return nil, err
}

// standard deferred cleanup - this is where the panic originates
defer func() {
    if session != nil {
        session.Close()  // ← panics if the query timed out
    }
}()

var timeout int64 = 1000
result, err := session.ExecuteQueryStatement(query, &timeout)
if err != nil {
    // error code 712 returned here (query timeout)
    // but before this error can be handled, the deferred
    // session.Close() above panics on the way out
    return nil, err
}

---

Call Stack

First the timeout error:

error   IOTDB operation failed  
{"error": "error code: 712, message: Current query is time out, 
query start time is 1771997424871, ddl is 1771997425871, 
current time is 1771997425872"}

Immediately followed by:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x775c96]

goroutine 218 [running]:
runtime/panic.go:792

github.com/apache/iotdb-client-go/v2/client.(*Session).Close(0xc002d6d2a8)
    client/tablesessionpool.go:151

github.com/apache/iotdb-client-go/v2/rpc/client.go:19901

github.com/apache/iotdb-client-go/v2/client.(*PooledTableSession).Close()
    client/sessionpool.go:168

// my application code
myapp/repository/iotdb.FetchTableData()
myapp/service/report.ReportService()

Why This Happens (What I Traced)
Looking at the library source, the sequence appears to be:

Query timeout corrupts the Thrift transport state
PooledTableSession.Close() calls SessionPool.PutBack()
PutBack calls session.trans.IsOpen() on the broken transport → panics
The recover() block in PutBack catches it but then calls session.Close() on a by-value copy of the session
That copy has a nil client field → nil pointer dereference at rpc/client.go:19901

Environment

iotdb-client-go version: v2.0.3-1
Go version: 1.xx
IoTDB server version: 2.x
OS: Linux

Notes

Only happens on query timeout — normal query flows work fine
The panic happens during session.Close() in deferred cleanup, not during the query execution itself
This crash takes down the entire service process, not just the failed query
Standard Go pattern of deferring session.Close() after GetSession() is what triggers it, so there is no way to avoid this without wrapping every session close in a recover as a workaround

[HTHou]

@shuwenwei Please take a look.

[shuwenwei]

#151 may fix your situation, and I tried to fix other issues in #153.

[KrishnajithUS]

Thanks for promptly addressing this issue. I think #153 this should fix the issue.