fix(query): always close client.conn in cancelQuery (issue #405)

[charredlot]

When the server closes the connection unexpectedly, the client will call cancelQuery (e.g. when client.packet fails). In client.cancelQuery, if client.flushBuf has data to flush, it will return a non-nil error and return early without calling conn.Close. This prevents the chpool from removing the client after client.Do and leaves the client.conn in a bad state such that future writes will always fail with a "broken pipe" error.

Summary

Checklist

Delete items not relevant to your PR:

• Unit and integration tests covering the common scenarios were added
• A human-readable description of the changes was provided to include in CHANGELOG

[CLAassistant]

All committers have signed the CLA.

[cwegener]

Interesting find. I am also seeing these error conditions when using the database/sql interface in clickhouse-go@v2.17.1

I do wonder though what is causing the unexpectedly closed connection in the server.

In my case, the TCP connection is via localhost. And my clickhouse server log says 'Broken pipe':

<Error> TCPHandler: Code: 210. DB::NetException: I/O error: Broken pipe, while writing to socket (127.0.0.1:9000 -> 127.0.0.1:41866). (NETWORK_ERROR),

[charredlot]

I do wonder though what is causing the unexpectedly closed connection in the server.

In my case, the TCP connection is via localhost. And my clickhouse server log says 'Broken pipe':

In our case, there was an https proxy restarting, so we expected disconnects. This PR doesn't change anything with respect to whether disconnects happen. I'll throw a random guess that maybe one of the conns in your pool hit an idle timeout? But you might get more traction with a reliable repro on the linked issue.