Description
After review next improvements are required:
- ConnectionImpl.java:694-699 — background abort failure is only rethrown inside an executor. Log once at ERROR/WARN because callers may never observe it.
- PreparedStatementImpl.java:419-420 — schema fallback logs full SQL but omits the exception. Include the cause and avoid raw SQL.
- Client.cancelTransportRequest():2413-2418 — unknown/stale query IDs silently no-op. A DEBUG message would help cancellation diagnosis.
- WriterStatementImpl.java:133-135 - need to log exception on debug level
- WriterStatementImpl.java:458-460 - need to log exception on debug level
- StatementImpl.java:202-204 - need to log exception on debug level
- HttpAPIClientHelper.java:1118-1120 - need to log exception on debug level
- ProcessParser.java:84-86 - need to log exception on debug level
Server errors are never logged at all. In HttpAPIClientHelper.executeRequest (lines 706-733), every non-2xx path throws — readError(...), ConnectException for 502/503, ClientException for unexpected status — with no log statement anywhere. readError builds a rich ServerException carrying the ClickHouse error code and message, and nothing records it. The only related logs, at lines 409 and 447, fire when the driver fails to read the error body, so a well-formed server error is completely invisible unless the application logs the exception itself. This is the single biggest gap; a WARN before the throws with query id, authority, status code, and the X-ClickHouse-Exception-Code header would cover it (truncate the body, and never log the Authorization / X-ClickHouse-Key headers).
Retry logging carries no context. All three retry loops in Client.java (lines 1502, 1708, 1852) log the bare string "Retrying." with the exception attached. There's no attempt number, no maxAttempts, no query id, and — most importantly — no indication of which endpoint failed or which one is being tried next, even though nodeSelector.getNextAliveNode(...) is called on the very next line. On exhaustion, LOG.warn(errMsg) at 1516/1735/1867 logs the message without the accumulated lastException, so the cause only survives on the thrown exception.
Startup configuration is nearly invisible. createHttpClient logs only compression (line 152) and the connection reuse strategy (line 251). Authentication mode, SSL mode and trust configuration, proxy settings, pool sizing, and the native-vs-Java LZ4 factory choice are all resolved silently. These are the settings people get wrong, and they're the hardest to reconstruct after the fact. One INFO line at client construction summarizing the resolved transport configuration — no secrets — would pay for itself.
Description
After review next improvements are required:
Server errors are never logged at all. In HttpAPIClientHelper.executeRequest (lines 706-733), every non-2xx path throws — readError(...), ConnectException for 502/503, ClientException for unexpected status — with no log statement anywhere. readError builds a rich ServerException carrying the ClickHouse error code and message, and nothing records it. The only related logs, at lines 409 and 447, fire when the driver fails to read the error body, so a well-formed server error is completely invisible unless the application logs the exception itself. This is the single biggest gap; a WARN before the throws with query id, authority, status code, and the X-ClickHouse-Exception-Code header would cover it (truncate the body, and never log the Authorization / X-ClickHouse-Key headers).
Retry logging carries no context. All three retry loops in Client.java (lines 1502, 1708, 1852) log the bare string "Retrying." with the exception attached. There's no attempt number, no maxAttempts, no query id, and — most importantly — no indication of which endpoint failed or which one is being tried next, even though nodeSelector.getNextAliveNode(...) is called on the very next line. On exhaustion, LOG.warn(errMsg) at 1516/1735/1867 logs the message without the accumulated lastException, so the cause only survives on the thrown exception.
Startup configuration is nearly invisible. createHttpClient logs only compression (line 152) and the connection reuse strategy (line 251). Authentication mode, SSL mode and trust configuration, proxy settings, pool sizing, and the native-vs-Java LZ4 factory choice are all resolved silently. These are the settings people get wrong, and they're the hardest to reconstruct after the fact. One INFO line at client construction summarizing the resolved transport configuration — no secrets — would pay for itself.