attachDockerNetworkWithRollback's docstring in tests/spike/clickhouse-client/clickhouse-containers.mjs:292-297 claims the port was "confirmed reachable at container-boot time by the caller before this runs" — but startRow calls it at line 419 before waitForReady at line 422. Nothing confirms reachability before the attach runs.
The function's 4×1s probePing (lines 277-289, 306) therefore races ClickHouse's own cold start rather than checking an already-confirmed-live port. Found live and reproducibly (3/3 runs) during #585 Phase 0 WebKit-browser-matrix flake research: current-altinity-stable is consistently the row that loses this race and gets silently rolled back to default-bridge-only networking, because it's booted last (sequential boot order in spike-server.mjs:167-173) under maximum accumulated Docker load — so its cold start is slowest and most likely to still be starting when the probe fires.
This is comment/invariant drift (the docstring asserts a precondition the call site doesn't actually provide) that makes container network topology depend on relative boot speed rather than a real readiness check. Low urgency — this harness is dev/spike-only, not production — but worth fixing before the harness is relied on again for a rerun of the #585 browser matrix, since it's a plausible contributor to that matrix's one flaky cell (see #585 ship-log / ADR-0005 evidence discussion).
Suggested fix: either call attachDockerNetworkWithRollback only after waitForReady resolves (matching the docstring's own claimed precondition), or have the docstring/precondition match reality (loosen probePing's retry budget, or make it wait for the same readiness signal waitForReady uses).
Found by: automated root-cause research launched from a /ship-adjacent session, 2026-08-06.
attachDockerNetworkWithRollback's docstring intests/spike/clickhouse-client/clickhouse-containers.mjs:292-297claims the port was "confirmed reachable at container-boot time by the caller before this runs" — butstartRowcalls it at line 419 beforewaitForReadyat line 422. Nothing confirms reachability before the attach runs.The function's 4×1s
probePing(lines 277-289, 306) therefore races ClickHouse's own cold start rather than checking an already-confirmed-live port. Found live and reproducibly (3/3 runs) during #585 Phase 0 WebKit-browser-matrix flake research:current-altinity-stableis consistently the row that loses this race and gets silently rolled back to default-bridge-only networking, because it's booted last (sequential boot order inspike-server.mjs:167-173) under maximum accumulated Docker load — so its cold start is slowest and most likely to still be starting when the probe fires.This is comment/invariant drift (the docstring asserts a precondition the call site doesn't actually provide) that makes container network topology depend on relative boot speed rather than a real readiness check. Low urgency — this harness is dev/spike-only, not production — but worth fixing before the harness is relied on again for a rerun of the #585 browser matrix, since it's a plausible contributor to that matrix's one flaky cell (see #585 ship-log / ADR-0005 evidence discussion).
Suggested fix: either call
attachDockerNetworkWithRollbackonly afterwaitForReadyresolves (matching the docstring's own claimed precondition), or have the docstring/precondition match reality (loosenprobePing's retry budget, or make it wait for the same readiness signalwaitForReadyuses).Found by: automated root-cause research launched from a
/ship-adjacent session, 2026-08-06.