Call VerifySuccess before return to user

[HTHou]

This pull request refactors the Session methods in client/session.go to standardize error handling and simplify method signatures. The main change is that several methods which previously returned both a status and an error now return only an error, with status verification handled internally. This makes the API easier to use and less error-prone for clients.

API simplification and error handling improvements:

• Changed multiple methods (such as SetStorageGroup, DeleteStorageGroup, DeleteStorageGroups, CreateTimeseries, CreateAlignedTimeseries, CreateMultiTimeseries, DeleteTimeseries, DeleteData, InsertStringRecord, SetTimeZone, ExecuteNonQueryStatement, InsertRecord, InsertAlignedRecord, InsertRecordsOfOneDevice, InsertAlignedRecordsOfOneDevice, InsertRecords, and InsertAlignedRecords) to return only an error instead of both a status and an error. Status checking is now done internally using VerifySuccess. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27]

Internal logic and consistency improvements:

• Updated all affected methods to call VerifySuccess after RPC calls and to return early if an error is encountered, ensuring consistent error propagation and reducing code duplication. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27]

These changes make the session API cleaner and help prevent misuse by encapsulating status verification and error handling within each method.

[Copilot]

Pull request overview

This PR simplifies the Go client session APIs by internalizing TSStatus verification (VerifySuccess) and updating many write/DDL-style methods to return only error. This reduces the chance of callers forgetting to validate status codes and standardizes error handling across the client.

Changes:

• Refactors many Session methods to return error only, calling VerifySuccess internally after RPCs.
• Updates table-session interfaces (ITableSession) and session pool wrappers to match the simplified signatures.
• Updates e2e tests and examples to use the new error-only APIs.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
client/session.go	Refactors many methods to return only error and verifies status internally.
client/tablesession.go	Updates ITableSession and TableSession methods to return error only.
client/tablesessionpool.go	Updates pooled table session wrappers to the new error-only API.
test/e2e/e2e_test.go	Adjusts e2e tests to the new error-only APIs.
test/e2e/e2e_table_test.go	Adjusts table e2e tests to the new error-only APIs.
example/session_example.go	Updates example code to handle error-only returns.
example/session_pool/session_pool_example.go	Updates session pool example code to handle error-only returns.
example/table/table_session_example.go	Updates table session example code to handle error-only returns.
example/session_pool/table/table_session_pool_example.go	Updates table session pool example code to handle error-only returns.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

PooledTableSession.Insert now drops/invalidates the pooled session on any returned error. Since insertRelationalTablet now calls VerifySuccess internally, non-success server status codes (e.g., user/SQL/data errors) will also cause the session to be dropped even though the connection is still healthy. Consider only dropping the session for transport/connection errors, or otherwise preserve a way to distinguish retryable/connection failures from application-level status errors.

[Copilot]

PooledTableSession.ExecuteNonQueryStatement drops the underlying session for any error returned by Session.ExecuteNonQueryStatement. After this refactor, that error can come from VerifySuccess (i.e., a non-success TSStatus) and not necessarily a broken connection. Dropping the session for application-level errors can cause unnecessary churn in the pool; consider only dropping on connection/transport failures.