[jdbc-v1] Statement.cancel() throws NOTHING_TO_KILL (785) on ClickHouse 26.11+ when the query is already finished

Read clickhouse-jdbc/src/main/java/com/clickhouse/jdbc/internal/ClickHouseStatementImpl.java, especially cancel() and its error handling around KILL QUERY. Compare the v1 behavior with the jdbc-v2 fix in #3271, then add coverage for cancel() after a query has finished and for cancellation of a running query. Done means error 785 is ignored while other errors still propagate and running queries can still be cancelled.

Description

In the legacy v1 JDBC driver (clickhouse.jdbc.v1=true), Statement.cancel() throws SQLException (error code 785, NOTHING_TO_KILL) on ClickHouse 26.11+ when the statement has no running query. This is the usual case when cancel() races with a query that has just finished.

Cause on the server side: ClickHouse 26.11 enables kill_throw_if_noop by default (ClickHouse/ClickHouse#125968, "Backward Incompatible Change"). A local KILL QUERY that matches no running query now fails with code 785. Before 26.11 the same statement returned an empty result.

This is the v1 equivalent of #3264 (jdbc-v2). The jdbc-v2 fix is in #3271. That PR says that the v1 driver is out of scope.

Steps to reproduce

1. Start ClickHouse 26.11 (clickhouse/clickhouse-server:head, tested on 26.11.1.888).
2. Connect with the v1 driver (clickhouse.jdbc.v1=true).
3. Run a query, read the result to the end, then call stmt.cancel().

Error Log or Exception StackTrace

java.sql.SQLException: Code: 785. DB::Exception: No query to kill. (NOTHING_TO_KILL) (version 26.11.1.888 (official build))
  errorCode=785 sqlState=07000

Results of the same program on two servers (compress=0 because of #3107):

Case	26.9.1.1629	26.11.1.888
cancel() on a statement that never ran a query	OK	OK
cancel() after executeQuery("SELECT 1") is fully read	OK	SQLException 785
cancel() after executeUpdate("DROP TABLE IF EXISTS ...")	OK	SQLException 785
cancel() while a long query runs	OK (query killed)	OK (query killed)

The server alone, without the client:

$ curl -u default:... http://localhost:8123/ --data-binary "KILL QUERY WHERE query_id='nope'"
Code: 785. DB::Exception: No query to kill. (NOTHING_TO_KILL) (version 26.11.1.888 (official build))
$ curl -u default:... "http://localhost:8123/?kill_throw_if_noop=0" --data-binary "KILL QUERY WHERE query_id='nope'"
(empty result, HTTP 200)

Expected Behaviour

cancel() does not throw when there is no running query to cancel. There is nothing to cancel, so the application should not get an error. This is the behavior on servers before 26.11, and the behavior that #3271 gives jdbc-v2.

Root cause: clickhouse-jdbc/src/main/java/com/clickhouse/jdbc/internal/ClickHouseStatementImpl.java (main @ 771b8bcca):

• line 360: queryId is set for each query and is not cleared when the query completes. So cancel() after a finished query still sends KILL QUERY WHERE query_id='<id>' (line 675).
• lines 684-685: catch (Exception e) { throw SqlExceptionUtils.handle(e.getCause()); } rethrows every server error, including 785.

Suggested fix: in cancel(), ignore a server error with code 785 (NOTHING_TO_KILL) and write a debug log. Keep these behaviors:

• Other KILL QUERY errors are still thrown.
• cancel() of a running query still kills it.
• The transaction abort after the KILL QUERY (request.getTransaction().abort()) still runs when 785 is ignored. Now the throw skips it (code reading).

Do not send kill_throw_if_noop=0: servers before 26.10 reject the unknown setting.

Code Example

Properties p = new Properties();
p.setProperty("user", "default");
p.setProperty("password", "...");
String url = "jdbc:clickhouse://localhost:8123/default?clickhouse.jdbc.v1=true&compress=0";
try (Connection conn = new com.clickhouse.jdbc.ClickHouseDriver().connect(url, p);
     Statement stmt = conn.createStatement()) {
    try (ResultSet rs = stmt.executeQuery("SELECT 1")) {
        while (rs.next()) { }
    }
    stmt.cancel(); // 26.11+: SQLException code 785; 26.9: no error
}

Configuration

Client Configuration

// URL: jdbc:clickhouse://<host>:8123/default?clickhouse.jdbc.v1=true&compress=0
// compress=0 only avoids #3107; it has no effect on this bug.

Environment

• Cloud
• Client version: main @ 771b8bcca (0.12.0-rc1-SNAPSHOT), clickhouse-jdbc module
• Language version: Java 17
• OS: Linux (Docker)

ClickHouse Server

• ClickHouse Server version: 26.11.1.888 (fails), 26.9.1.1629 (works)
• ClickHouse Server non-default settings, if any: none (kill_throw_if_noop is 1 by default in 26.11)
• CREATE TABLE statements for tables involved: none

---

Found by automated analysis (Polyglot AI) while working on #3264 (jdbc-v2). Verified against live 26.11 and 26.9 servers, not by code reading only.