You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
chore: pin bun to an exact version above the known-bad range
Bun's node:http client occasionally drops the terminating chunk of an empty
chunked HTTP response. When that happens a ClickHouse read never completes,
and the client's request_timeout cannot rescue it: that timeout is implemented
with socket.setTimeout, which Bun's node:http client ignores. The call hangs
forever rather than failing.
Measured against a real clickhouse-server:24.8 with bursts of zero-row queries
through @clickhouse/client: about 1% of bursts hang on 1.3.9, and none on
1.3.12 or later (0 in 16000 queries on both 1.3.12 and 1.3.14). This is what
had been intermittently hanging the ClickHouse schema integration tests in CI
at bun's 5000ms per-test timeout.
CI already ran 1.3.12 and was therefore already unaffected, but nothing said
that the pin was load-bearing, and the other pins had drifted: publish.yml was
still on 1.3.9, the images used the floating oven/bun:1.3 tag, and the research
compose file ran the archive forwarder on bun 1.2. The runtime version of the
service that reads and writes ClickHouse continuously was consequently decided
by image build date.
Pin every workflow and image to 1.3.14 — the newest 1.3.x, which is what the
floating tag resolves to today, so no image is downgraded — and state the
constraint at each pin site, since it is invisible from the code.
Verified: 30 consecutive runs of the ClickHouse schema integration suite on
1.3.14 against a persistent instance, all green; oven/bun:1.3.14 pulls and
runs; every touched YAML parses; bun run check, check:server-lines and
typecheck:sidecar all pass.
0 commit comments