Area: app · infra — test gap · found via #603's follow-ups (PR body)
Expected: turning on clickhouse.tls.enabled is exercised end-to-end somewhere, so a regression that quietly drops TLS from the native hop fails a test rather than shipping. The repo already holds the precedent: tests/integration/otel_test.go:323 pins the https:// → TLS dial path against a fake TLS receiver, because "a regression that broke the TLS path would otherwise go unnoticed."
Actual: #603 says it plainly — "Native TLS is covered by the Options test only; the integration harness runs a plaintext ClickHouse." The unit test asserts chconn builds the right tls.Config and hands it to the driver's Options; nothing checks the driver then negotiates TLS. tests/integration/setup_test.go:240 writes every tenant's config with tls.enabled: false, and tls/https appear nowhere else under tests/integration/. The HTTP hop is better off: #603 covers an INSERT and a proxied query over httptest.NewTLSServer, accepted with the server certificate as the authority and refused without it.
Impact: the native connection is the one that carries the ClickHouse credentials, and it is the half with no end-to-end exercise. A change to how Options is assembled — or a driver upgrade that reads the field differently — would pass make ci while every deployment fell back to plaintext, which no client-side error reports.
Scope: a native-hop equivalent of the Options test that completes a handshake, or a TLS-enabled ClickHouse in the integration harness. The httptest.NewTLSServer shape #603 used for the HTTP hop is the cheaper of the two.
Related: #603, #610, #583 (story 6)
From #603's "Follow-ups" section (taitelee), no story owns it — story 6 is closed; validated by code-read against 93d80198 on 2026-09-25. Filed by the pm-triage routine.
Area: app · infra — test gap · found via #603's follow-ups (PR body)
Expected: turning on
clickhouse.tls.enabledis exercised end-to-end somewhere, so a regression that quietly drops TLS from the native hop fails a test rather than shipping. The repo already holds the precedent:tests/integration/otel_test.go:323pins thehttps://→ TLS dial path against a fake TLS receiver, because "a regression that broke the TLS path would otherwise go unnoticed."Actual: #603 says it plainly — "Native TLS is covered by the
Optionstest only; the integration harness runs a plaintext ClickHouse." The unit test assertschconnbuilds the righttls.Configand hands it to the driver'sOptions; nothing checks the driver then negotiates TLS.tests/integration/setup_test.go:240writes every tenant's config withtls.enabled: false, andtls/httpsappear nowhere else undertests/integration/. The HTTP hop is better off: #603 covers anINSERTand a proxied query overhttptest.NewTLSServer, accepted with the server certificate as the authority and refused without it.Impact: the native connection is the one that carries the ClickHouse credentials, and it is the half with no end-to-end exercise. A change to how
Optionsis assembled — or a driver upgrade that reads the field differently — would passmake ciwhile every deployment fell back to plaintext, which no client-side error reports.Scope: a native-hop equivalent of the
Optionstest that completes a handshake, or a TLS-enabled ClickHouse in the integration harness. Thehttptest.NewTLSServershape #603 used for the HTTP hop is the cheaper of the two.Related: #603, #610, #583 (story 6)
From #603's "Follow-ups" section (taitelee), no story owns it — story 6 is closed; validated by code-read against
93d80198on 2026-09-25. Filed by the pm-triage routine.