Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[client-v2] Every compressed read fails on ClickHouse 26.9+: response reader is hardcoded to LZ4 but the server default codec is now ZSTD(3)

クローズ
  • 何か問題がありますか？
#3,105 コメント 4 件 リアクション 1 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
64/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
java
領域
databases

調査の方向性

client-v2 の ClickHouseLZ4InputStream.java から開始し、特に 112 行目の refill パスを確認して、圧縮された HTTP レスポンスが getTableSchema やその他の読み取りで使用されるレスポンスリーダーにどのように到達するかを追跡します。compress=1 を指定して clickhouse/clickhouse-server:head に対して再現し、その後、圧縮された LZ4、ZSTD、および非圧縮のレスポンスが、それぞれのフレームメソッドバイトに従って処理され、既存の読み取りを壊さないことを確認します。

索引モデルが issue の本文から書いたものです。

説明

Summary

ClickHouse #108786 ("Switch the default compression to ZSTD(3) for table data and network", merged 2026-09-05, Version info says merged into 26.9.1.810, so included in 26.9 and later) changes CompressionCodecFactory::getDefaultCodec from LZ4 to ZSTD(3).

The HTTP compress=1 framed output is one of the direct getDefaultCodec users. client-v2 requests compress=1 by default and pipes the response body through ClickHouseLZ4InputStream, which asserts the LZ4 block magic byte, so every compressed read fails against ClickHouse 26.9+:

com.clickhouse.client.api.ClientException: Invalid LZ4 magic byte: '-112'
	at com.clickhouse.client.api.internal.ClickHouseLZ4InputStream.refill(ClickHouseLZ4InputStream.java:112)
	at com.clickhouse.client.api.internal.ClickHouseLZ4InputStream.read(ClickHouseLZ4InputStream.java:62)
	...
	at com.clickhouse.client.api.internal.TableSchemaParser.readTSKV(TableSchemaParser.java:23)
	at com.clickhouse.client.api.Client.getTableSchemaImpl(Client.java:1872)
	at com.clickhouse.client.api.Client.getTableSchema(Client.java:1847)

getTableSchema is just where we hit it first — this is not specific to schema introspection, it affects any compressed response.

Per that PR's own changelog, the HTTP compress=1 path has no runtime rollback: it is not controlled by the compatibility setting, per-column CODEC, or the server <compression> config. So this cannot be worked around server-side.

Affected versions
  • client-v2 0.9.5 — verified failing
  • client-v2 0.10.0 (latest release) — same ClickHouseLZ4InputStream with the same Invalid LZ4 magic byte check, so also affected
  • Server: ClickHouse 26.9+ (reproduced on clickhouse/clickhouse-server:head = 26.9.1.943). 26.8 and earlier are unaffected by this bug.
Root cause / evidence

-112 is 0x90 signed. Raw curl against 26.9.1.943 confirms the framing:

$ curl -s -u default:x 'localhost:8123/?compress=1' --data-binary 'DESCRIBE TABLE t FORMAT TSKV' | xxd | head -2
00000000: 151e 70e4 4490 8555 b0c4 8424 d0d8 731d  ..p.D..U...$..s.
00000010: 9065 0000 00c0 0000 0028 b52f fd20 c09d  .e.......(./. ..

After the 16-byte checksum, offset 0x10 is 0x90 — the compression method byte for ZSTD, exactly the byte reported in the exception — and offset 0x18 is 28 b5 2f fd, the ZSTD magic number. ClickHouseLZ4InputStream expects 0x82 there.

The same request without compress=1 returns plain readable TSKV.

Reproduce
docker run -d --name chhead -e CLICKHOUSE_PASSWORD=x -p 8123:8123 clickhouse/clickhouse-server:head
# then any client-v2 read, e.g.
# client.getTableSchema("t", "default")
Suggested fix

The compressed frame is self-describing — ClickHouse#108786 explicitly relies on "the receiver auto-detects the codec", which holds for the server's own readers. client-v2 does not auto-detect; it assumes LZ4. The response reader should dispatch on the compression method byte in the frame header (0x82 LZ4, 0x90 ZSTD, 0x02 none) rather than asserting LZ4, and gain a ZSTD decompression path.

Note on interaction with #3070 / #3094

On 26.9+ this bug currently masks the X-ClickHouse-Format precedence bug (#3070, #3094): the stream dies in refill before readTSKV ever sees bytes. I verified the header bug is still present on 26.9.1.943 — curl -H 'format: TSKV' ... --data-binary 'DESCRIBE TABLE t' returns TabSeparated there too. So fixing only this issue will move getTableSchema back to failing with Non-null columnName and columnType are required; both need to land.

Setting compressServerResponse(false) sidesteps this issue alone, but for the same reason it is not a usable workaround for getTableSchema, and it costs compression on every read.

Context

Found while running the ClickHouse Flink connector test suite against ClickHouse HEAD.

主要言語
Java
スター
1.6k
フォーク
638
平均マージ
2日 46分
マージ済み PR（30日）
46

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ClickHouse/clickhouse-java のほかの issue

ClickHouse/clickhouse-java の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。