feat(qwp): connect timeout, ingest callbacks, and lazy_connect (tolerant startup) on the QuestDB facade

[bluestreak01]

tandem OSS PR: questdb/questdb#7341

Summary

Related ergonomics/resilience improvements for the QWP (WebSocket) client:

1. Application-level TCP connect timeout (transport-wide) — bound the connect itself instead of riding the OS-level timeout.
2. Expose the ingest callbacks on the QuestDB facade — errorHandler / connectionListener, previously unreachable from the pooled facade.
3. Tolerant startup via lazy_connect=true — start the handle even when the server is down, buffer writes meanwhile, and read once it's up. Reads stay fully enabled.
4. Single cluster config on the facade — one ws/wss string (a single addr server list) configures the whole cluster, driving both the ingest and query pools.
5. Pooled-lease refactor + correctness fixes — reads and writes share one pooled-lease model (borrowQuery() mirrors borrowSender()), and a per-borrow generation closes a family of pool-corruption bugs (double-close, use-after-close, lost dispatch, stale cancel). This is internal hardening — see §5.

Items 1–3 are independently usable and off by default.

---

1. Configurable TCP connect timeout

A connect to a black-holed/firewalled host blocks on the OS-level TCP connect timeout (60–120s): the socket is created blocking, connect() runs, then it's switched to non-blocking. The code calls this out:

// SenderPool.java
// connect to a black-holed/firewalled host blocks on the OS connect timeout
// (the transport exposes no application-level connect timeout to clamp it).

Approach (native, cross-platform): non-blocking connect() (EINPROGRESS) → poll/select for writability bounded by the caller's budget → confirm via getsockopt(SO_ERROR). A sentinel (CONNECT_TIMEOUT = -3) lets Java raise a timeout-flagged exception. Generalises the existing handleEintrInConnect helper.

Sender.builder("https::addr=host:9000;connect_timeout=5000;")...   // or .connectTimeoutMillis(5000)
QwpQueryClient.fromConfig("ws::addr=host:9000;connect_timeout=5000;");

Touches: native share/net.c + windows/net.c + net.h; Net / NetworkFacade(Impl); HttpClientConfiguration.getConnectTimeout(); HttpClient.connect() / WebSocketClient.doConnect(); ConfigSchema COMMON key connect_timeout; Sender builder + both parsers; QwpWebSocketSender / QwpQueryClient (withConnectTimeout). Bounds the TCP connect and the TLS handshake (see below); the WebSocket upgrade stays under the request/auth timeout (auth_timeout_ms).

1b. Bound the TLS handshake (and stop it busy-spinning)

JavaTlsClientSocket.startTlsSession ran the TLS handshake with raw recv/send on the now-non-blocking socket and never waited on readiness. A peer that completed the TCP connect but stalled before its half of the handshake left the engine in NEED_UNWRAP with recv returning 0 (would-block), so the loop re-read in a tight cycle: a 100% CPU busy-spin with no deadline. connect_timeout bounded only the TCP connect, and the upgrade's request/auth timeout never covered the handshake, so a stalled wss:// host (e.g. QuestDB Cloud) could pin a core indefinitely and defeat the bounded connect. The busy-spin pre-dates this PR (it predates the connect_timeout work), but the same change closes it.

The handshake now runs through the client's existing deadline-aware ioWait (the same primitive recvOrDie/doSend use): when the socket would block it parks on epoll/kqueue/select for the remaining connect budget and throws a timeout-flagged exception once it is spent. doConnect registers the fd with the event loop before the handshake and bounds it by connect_timeout, falling back to the request timeout when connect_timeout is unset — so the handshake can no longer hang or spin even with the default config. Both HttpClient (https) and WebSocketClient (wss) share the fix, and the connect TLS block disconnects on any handshake error so the fd/native buffers do not leak.

Tradeoff: with connect_timeout unset, a wss:// handshake that stalls now fails after the request timeout instead of spinning/hanging forever. That is strictly better, but it is a behavior change for that edge.

Touches: JavaTlsClientSocket (handshake extracted into runHandshake), new SocketReadinessWaiter, Socket/PlainSocket, HttpClient.connect() / WebSocketClient.doConnect(). Tests: JavaTlsClientSocketTest.testHandshakeWaitsForReadabilityInsteadOfBusySpinning (a stalled peer must yield to the readiness waiter, not spin; a method-level timeout fails the test if the spin returns) and testHandshakeCompletesWithoutWaitingWhenEngineMakesProgress (happy path).

---

2. Ingest callbacks on the QuestDB facade

The facade built ingest senders from config strings only (SenderPool → Sender.fromConfig), so the programmatic SenderErrorHandler / SenderConnectionListener were unreachable — a facade user got the default loud-not-silent handlers with no way to observe async ingest errors or connection transitions.

QuestDB.builder()
    .fromConfig("ws::addr=host:9000;")
    .errorHandler(myErrorHandler)
    .connectionListener(myConnectionListener)
    .build();

QuestDBImpl / SenderPool each gain a full constructor carrying the callbacks; the white-box test-seam constructors are preserved as delegating shims. SenderPool.applyUserCallbacks() applies them to every pooled sender (non-SF and SF paths); internal recovery delegates are excluded. Defaults null.

---

3. Tolerant startup: lazy_connect=true

The facade prewarms a reader (QueryClientPool) synchronously and fail-fast (default query_pool_min=1; queries have no async connect), so a down server failed the whole build. The fix is a single connect-string flag that makes the handle tolerate a down server without giving up reads — "starts when the server is down" and "never reads" are different things, and you almost always want the first.

lazy_connect=true:

• a) starts even when the server is down — the ingest side goes async and the read pool defaults to query_pool_min=0, so neither side fail-fasts and build() returns promptly;
• b) buffers writes while down — the async sender accepts rows that flush once the wire is up;
• c) reads once the server is up — the read pool stays enabled (it is not disabled the way a write-only mode would). It defaults to query_pool_min=0, so nothing connects eagerly and borrowQuery() connects lazily on first use. While the server is still down a borrowQuery() throws (it has nowhere to connect — exactly like any read against a down server); once the server is up it connects and reads. The point is that lazy_connect defers the read connect rather than refusing reads.

// starts with no server present; writes buffer, reads work once it's up
try (QuestDB db = QuestDB.connect("ws::addr=host:9000;lazy_connect=true;")) {
    try (Sender s = db.borrowSender()) {
        s.table("t").longColumn("v", 1).atNow();    // buffers while the server is down
    }
    // ... later, once the server is up:
    try (Query q = db.borrowQuery()) {               // read pool connects lazily on first borrow
        q.sql("select 1").handler(handler).submit().await();
    }
}

Because both sides must start non-blocking, a knob that forces a blocking / fail-fast startup is a configuration conflict, rejected up front with a clear remedy rather than silently overridden:

• initial_connect_retry other than async (i.e. off/false/on/true/sync), and
• an explicit query_pool_min > 0 (connect string or builder call).

lazy_connect is a Side.POOL registry key — the two ws clients ignore it; the facade reads it, defaults query_pool_min to 0, and injects initial_connect_retry=async when the user set none.

---

4. Single cluster config on the facade

A QuestDB cluster is one logical target reached over QWP for both ingest and query, so the facade takes one cluster config: a single ws/wss string that lists every node in one addr server list and drives both the sender and query pools.

QuestDB.builder()
    .fromConfig("ws::addr=node1:9000,node2:9000,node3:9000;")  // whole cluster
    .errorHandler(myErrorHandler)
    .connectionListener(myConnectionListener)
    .build();

build() validates the one string with both the ingest (validateWsConfigString) and egress (QwpQueryClient.validateConfig) validators; each side applies the keys it owns and ignores the rest. Pool keys are read from a single ConfigView, and QuestDBImpl passes the one config to both pool slots (preserving the white-box reflection seam).

---

5. Pooled-handle lifecycle: lease/generation refactor + correctness fixes

This is the bulk of the diff and it is internal (no user-facing API beyond the borrow methods). It reshapes the facade so reads and writes share one pooled-lease model and fixes a family of pool-corruption bugs that the previous thread-affine / flag-guarded design allowed.

Refactor — symmetric pooled lease (1245c17). Reads and writes now use one model:

• Ingest: remove QuestDB.sender() / releaseSender() and the entire thread-pin subsystem behind them (pinToCurrentThread, releaseCurrentThread, clearPinIfCurrent, the threadAffine ThreadLocal, the PooledSender invalidated flag). borrowSender() is now the only way to lease a Sender.
• Egress: remove query(), newQuery(), and executeSql(); add QuestDB.borrowQuery(), a closeable, non-allocating Query lease that mirrors borrowSender(). Each pooled QueryWorker owns one pre-allocated QueryImpl, handed out reset on borrow; submit() dispatches on the held worker (single-flight) and close() returns it to the pool. Reads now connect at borrow time, so under lazy_connect the read pool defaults to query_pool_min=0 and build() does not fail-fast while the server is down. (This is why §3's read example uses borrowQuery() and not the removed executeSql.)

Correctness fixes carried on top of the refactor:

• f39e846 (M1) — stale pooled handle can corrupt the pool under double-close / use-after-close. The pooled handle was the reused per-slot object guarded by a non-volatile in-use flag, so a stale handle's close()/cancel()/write could leak into a different borrow (double-release → two concurrent borrowers on one non-thread-safe client). Fix: every borrow gets its own immutable generation, stamped under the pool lock and re-checked on every op — close()/cancel() no-op on a stale generation (idempotency preserved), submit()/writes throw, and release re-checks the generation under the lock so a slot can never be enqueued twice. Introduces QueryLease (wrapping QueryImpl) and SenderSlot (with PooledSender as the per-borrow wrapper).
• e30a59c — lost query-worker dispatch under single-flight reuse. runLoop() cleared current outside signalLock, so a fast submit() → await() → submit() loop could clobber a freshly dispatched job and discard its signal, hanging the caller forever. Fix: clear current under signalLock at the moment of consumption. (Surfaced as a 60s hang in testSustainedMixedConcurrency, mostly on aarch64 CI; 15/15 clean with the fix.)
• bcb1e7a — watchdog cancel must re-check the lease generation under the pool lock. cancel(gen) validated the generation with an unlocked volatile read then issued the wire cancel separately — a TOCTOU where a watchdog could abort a new borrower's query with a spurious STATUS_CANCELLED. Fix: route through QueryClientPool.cancelIfCurrent(worker, gen), which re-checks and cancels under the same lock the generation is bumped under; close()'s abort-on-unawaited-close uses the same path.
• f64567e — assert the lease wraps the same pooled QueryImpl. Pins the invariant that the freshly allocated per-borrow wrapper delegates back to the one pre-allocated, reused QueryImpl (so a regression that allocated per borrow would be caught).

---

Testing

• NetConnectTimeoutTest — loopback success, refused-vs-timeout disambiguation, black-hole timeout within budget.
• QuestDBFacadeCallbacksTest — facade-wired errorHandler receives the async budget-exhaustion SenderError; connectionListener observes connection events (no server needed).
• QuestDBLazyConnectTest — lazy_connect=true starts + buffers a write with the server down, keeps the read pool enabled (borrowQuery() deferred to first use, not disabled), and rejects both conflicts (blocking initial_connect_retry, explicit query_pool_min > 0) from the connect string and from builder calls; QuestDBServerRecoveryTest dogfoods lazy_connect=true for the full down → write → up → read lifecycle.
• QueryLeaseGenerationTest / SenderLeaseGenerationTest — the per-borrow generation guard: double-release, cross-borrow cancel/write, and the concurrent stale-cancel-after-reborrow TOCTOU (testConcurrentCancelDoesNotReachClientAfterReborrow).
• QuestDBServerRecoveryTest — full lifecycle: server down → facade starts → client writes (buffered) → server starts → write side reconnects and the reader connects on the first borrowQuery().
• QuestDBBuilderTest — covers the single cluster-config surface; the shared-vocabulary and sender-pool-unwind tests run against one server with one config.
• TestWebSocketServer now serves both pools from one config like a real node: SERVER_INFO is emitted only on the egress /read path (the ingest /write ACK stream would choke on it), plus a setRejectReadUpgrade() toggle to fail only the query upgrade.

Full impl + network + facade suites pass locally on JDK 8 (source of truth) and the surface compiles on JDK 25 (java11+ front).

CI / native

• ci(native): the rebuild_native_libs.yml linux-x86-64 job moved from manylinux2014 (glibc 2.17) to manylinux_2_28 (glibc 2.28), mirroring linux-aarch64 — GitHub now forces actions onto Node 24 (glibc ≥ 2.27), which couldn't run in the 2.17 container (pre-existing breakage, unrelated to the C change).
• Native libraries are built on the test/release runners (no longer committed).

Compatibility

The connect_timeout knob and the ingest callbacks are additive and off by default. The QuestDB facade is new in this PR; the legacy direct Sender and QwpQueryClient APIs are unaffected.

Note: the PR bundles several independent features. Happy to split any of them into standalone PRs off main if that's easier to review.

[bluestreak01]

🤖 Automated code review — level-3 multi-agent pass

Review base: reviewed against the PR head 7948635 (gh pr diff + fetched refs/pull/60/head). Line numbers are PR-head. Heads-up: a local checkout of this branch can sit a few commits behind — the bounded Query.close() drain (7948635), the result-handler reentry guard (21becac), and the vacuous-assertion fix (d6bdbdf) are part of the PR head, so make sure they're in whatever finally merges.

Verdict: one blocking item (C1), plus test-hardening. Otherwise solid — Java-8-clean, no production resource leaks, no broken out-of-diff callsites, no data-path perf regressions; the M1 double-close and watchdog-TOCTOU fixes have deterministic regression tests (verified by reverting them).

🔴 Blocking

C1 — QueryWorker.runLoop can drop a dispatch on shutdown → caller's await() hangs forever
core/src/main/java/io/questdb/client/impl/QueryWorker.java:272

The outer while (!shuttingDown) exits after runOn() returns without re-inspecting current. Interleaving:

1. worker is inside runOn(q1); the terminal callback runs inline here, signals done, wakes the app thread
2. app: await(q1) returns → submit(q2) → dispatch(q2) reads shuttingDown==false and sets current=q2
3. another thread: QuestDB.close() → queryPool.close() → worker.shutdown() sets shuttingDown=true (close() shuts down borrowed/busy workers too)
4. worker returns from runOn(q1), re-checks :272, sees shuttingDown, exits without stranding current=q2
5. app's await(q2) blocks forever — q2 never reached the client, so no terminal event / backstop arrives

The strand logic at :279 only covers the parked worker, and testShutdownRacingDispatchMustNotStrandCaller only exercises that path (the busy path is untested). Reachable whenever one thread runs a submit→await→submit loop on a borrowed Query while another closes the handle.

Fix: change :272 to while (true) so the worker always re-enters the signalLock block; the existing if (shuttingDown) strand plus dispatch()'s own shuttingDown check then cover every ordering, and it still exits via the existing return. (Subtle interleaving — worth a second reviewer confirming.)

🟠 Moderate

• M5 — vacuous assertion in the only flush-Error→discard test. SenderPoolErrorSafetyTest.flushErrorDiscardsBrokenSenderInsteadOfRecycling:107 asserts assertNotSame(first, second) on two pool.borrow() results, but SenderPool.borrow() always returns a fresh PooledSender (SenderPool.java:677,725) — so it can never fail, and the RED case (broken sender recycled via giveBack instead of discardBroken) passes too. d6bdbdf fixed this exact pattern in the SenderPoolTest sibling (slotOf(...), line 65) but missed this one, which is the only coverage of the flush-Error path. Fix: add a slotOf() helper and assert assertNotSame(slotOf(first), slotOf(second)).

• M6 — two TLS handshake tests leak 768KB native; assertMemoryLeak doesn't catch it. JavaTlsClientSocketTest.testHandshakeWaitsForReadabilityInsteadOfBusySpinning and testHandshakeCompletesWithoutWaitingWhenEngineMakesProgress call prepareInternalBuffers() (3×256KB) but leave state == STATE_EMPTY, so close() returns early without freeInternalBuffers(). The recv/send sibling tests avoid this with setIntField(socket,"state",2) before close; these two omit it. (The leak slips past assertMemoryLeak because it's confined to one MemoryTag — a separate pre-existing harness gap worth confirming.) Fix: set state before close, matching the sibling tests.

• M1 — the lost-dispatch fix has no deterministic in-tree regression test. Reverting current=null-at-consumption in QueryWorker.runLoop leaves the in-tree suite green; the named testSustainedMixedConcurrency is parent-repo + probabilistic. A deterministic latch-based test (block the worker after signalDone but before returning from runOn, re-submit, assert under @Test(timeout=…)) would also cover C1's fix.

• M2 — missing cross-context tests: a real wss:// connect against a TCP-complete-but-TLS-stalled peer bounded by connect_timeout (TlsProxy exists but is never instantiated); the handshake-failure disconnect() (no fd/buffer leak) is unasserted; the recovery-delegate callback-exclusion negative path is untested.

• M3 — weak close-drain tests: QueryCloseDrainTest.testCloseReturnsWorkerWhenAlreadyDrained passes with the fix reverted (characterization, not regression); the shutdown() thread.interrupt() line is pinned by no test.

• M4 — stale comment: SenderPoolErrorSafetyTest:47-48 still says the fake is "injected ... by reflection," but it now uses the public @TestOnly ctor (the sibling SenderPoolSfTest was updated).

🟡 Minor / nits

• connect_timeout silently truncates to int on the ws/wss path: Sender.java:3484 and QwpQueryClient.java:393 do (int) view.getLong("connect_timeout", 0), but the schema allows up to Long.MAX_VALUE. Values > Integer.MAX_VALUE truncate to a wrong small timeout, or throw a confusing "connect_timeout must be > 0: -…" for a positive input. Cap the schema max at Integer.MAX_VALUE (sibling auth_timeout_ms already clamps via Math.min(..., Integer.MAX_VALUE)).
• QueryImpl.close():148 runs rejectHandlerReentry("close") before the stale-generation check (:155), so a stale close from a handler thread throws instead of the contractual idempotent no-op. cancel() already orders the gen-check first; reorder for consistency.
• Pre-existing TLS spin (cheap to harden): runHandshake's while (status != FINISHED) has no default/NOT_HANDSHAKING case — a JSSE provider that completes the handshake via a delegated task would spin without parking on the waiter. Not stock-JDK-reachable, but since this PR's goal is spin-elimination, a one-line default:-throws closes it.
• getBool undertested: the only ConfigView bool test targets the sibling getBoolOnOff; getBool's false/off acceptance and invalid-value throw (used by lazy_connect) are uncovered.
• net.c deadline comment claims "strict upper bound / only ever under-shoots," but the negative-ns ms-truncation can overshoot by <1ms (harmless — fix the comment).
• Test DRY: the Proxy-based fake Sender is duplicated 3× (SenderPoolErrorSafetyTest, QuestDBImplErrorSafetyTest), awaitTrue 2–3×, and the SSLEngine stubs 2×; redundant Class.forName + reflective ctor for the public QueryWorker in QueryImplResetTest (use new QueryWorker(...)).
• Other nits: QuestDBBuilder.java:73 config field is out of alphabetical order; 5-digit magic numbers without _ separators in the config-honored tests; SenderPoolTest:200-202 and QuestDBLazyConnectTest.testLazyConnectKeepsReadsEnabledWhileServerDown have near-vacuous assertions (count / db != null), covered more meaningfully elsewhere.

Process

The PR bundles ~6 semi-independent concerns plus a CI/native overhaul. Consider splitting the §5 lease/concurrency core and the CI/native build changes for isolated review and bisectability. The title omits §5 (the riskiest part — M1 double-close, the TOCTOU cancel, C1); surface it in the squash message since branch history is throwaway.

_{Generated by Claude Code (multi-agent review). Findings were verified against source; ~6 draft findings were dropped as false positives. Treat C1 as the one must-fix; the rest is polish / test-hardening.}

[bluestreak01]

Automated review — level-3 multi-agent pass

Reviewed against PR head 1570c5a (fresh-context reviewers covering correctness/concurrency, resource/perf, native C/JNI, cross-context callers, fresh-adversarial, and test efficacy/quality; every finding verified against source).

Verdict: approve with minor follow-ups. The concurrency-heavy lease/generation core is correct, the native connect-timeout + glibc pin are sound and CI-guarded, and no in-diff or out-of-diff correctness bug survived verification. The prior blocker C1 (busy-worker shutdown-drop) is fixed here (QueryWorker.runLoop is while (true) with a single strand point inside signalLock), as are the earlier M5 (vacuous flush-Error assertion) and M6 (TLS test buffer leak).

🔴 Critical

None.

🟠 Moderate

M1 — HTTP-ILP TLS-handshake timeout is not flagged as a timeout (in-diff). HttpClient.connect drives the handshake waiter via remainingTime(...) (HttpClient.java:191-197), which throws a non-flagAsTimeout() HttpClientException. Inconsistent with the TCP connect-timeout on the same path (HttpClient.java:630, flagged) and with WebSocketClient, which routes the handshake through getRemainingTimeOrThrow(...) and does flag it (WebSocketClient.java:1030-1036). Impact is cosmetic today (AbstractLineHttpSender retries on any HttpClientException regardless of isTimeout()), but the handshake bounding is new behavior, so a caller/telemetry keying on isTimeout() on the legacy ILP path would misclassify a mid-handshake stall. Fix: use getRemainingTimeOrThrow on the HTTP handshake path (or add .flagAsTimeout() in remainingTime).

M2 — Test-regression gaps.

• The head-commit fix (1570c5a, add NOT_HANDSHAKING to the handshake-loop exit, JavaTlsClientSocket.java:521) has no regression test: the only happy-path test uses ProgressingUnwrapSslEngine returning FINISHED, so the loop exits on the FINISHED clause and deleting && … != NOT_HANDSHAKING leaves both TLS tests green. No stub returns NEED_TASK. Add an engine that finishes via NEED_TASK/NOT_HANDSHAKING.
• The lost-dispatch fix (clear current under signalLock at consumption) has no in-repo regression — acknowledged in QueryWorkerTest javadoc; only covered end-to-end in the parent repo.
• Missing coverage: ConfigView.getBool false/off/invalid; recovery-delegate callback exclusion (SenderPool.buildManagedSlotSender forRecovery guard); handshake-error disconnect() (no fd/TLS-buffer leak); the connect_timeout TCP path is Assume-skipped on runners without a route to TEST-NET-1, so the core regression may not run in CI.

🟡 Minor

• connect_timeout truncation. Sender.java:3481 and QwpQueryClient.java:393 do (int) view.getLong("connect_timeout", 0) but the schema allows up to Long.MAX_VALUE. Values in (2^31, 2^32) become negative → confusing "must be > 0" on a positive input; ≥2^32 silently truncate. Clamp the schema max to Integer.MAX_VALUE (as auth_timeout_ms does).
• ConfigView.getBool is case-sensitive (only lowercase true/false/on/off; values are stored raw), so lazy_connect=TRUE throws — inconsistent with initial_connect_retry (equalsIgnoreCase). Also lazy_connect is registered boolOnOff (on/off) but read via getBool (true/false/on/off).
• Facade javadoc overstates zero-allocation. QuestDB.java:34-36/88-89/113-114 claim borrows are "zero at steady state / a pre-allocated handle," but each borrowQuery()/borrowSender() allocates a fresh QueryLease/PooledSender (JIT usually scalar-replaces in try-with-resources). Contradicts the accurate QueryLease/PooledSender javadoc. Only the submit/data path is truly allocation-free.
• Weak/near-vacuous tests. SenderPoolTest.testPoolBuildsRequestedNumberOfSenders:213-215 asserts assertNotSame on wrappers borrow() always makes fresh — assert pool.totalSize()==3 (or slotOf(...)). QuestDBLazyConnectTest.testLazyConnectKeepsReadsEnabledWhileServerDown:77 only asserts assertNotNull(db) (never null) and never calls borrowQuery() despite its name.
• QueryImpl.close(gen) ordering. Runs rejectHandlerReentry("close") before the stale-generation check (:148 vs :155); cancel() already checks gen first. Reorder for idempotency-contract consistency (very low impact).
• Test hygiene: assertMemoryLeak omitted in native-allocating white-box tests (QueryLeaseGenerationTest, QueryWorkerTest, QueryCloseDrainTest, QueryImplResetTest, SenderLeaseGenerationTest); awaitTrue duplicated (QuestDBServerRecoveryTest, QuestDBBuilderTest) → TestUtils.
• Concurrent double-close() of one live PooledSender double-flushes the non-thread-safe delegate (fast-path gen check + flush() before any lock). App-misuse only (handle documented not thread-safe); sequential/stale double-close is correctly idempotent. Very low.
• CI/build: mac-x64 test agent removed from run_tests_pipeline.yaml — darwin-x86-64 is still built/released (maven_central_release.yml:160-161) but loses CI test coverage. rebuild_native_libs.yml still git adds the binaries this PR otherwise removes (vestigial — running it re-commits them). A fresh checkout now needs a native build before mvn -pl core test (else UnsatisfiedLinkError) — worth a dev-setup note. net.c:330-333 comment overstates "only ever under-shoots by <1ms" (harmless).

Downgraded (false positives / already resolved — verified)

• "No CI guard on the resulting .so glibc floor" — dismissed: the PR adds .github/scripts/check-glibc-floor.sh, wired into ci.yml:161, rebuild_native_libs.yml:114/154, maven_central_release.yml:299/366 (floor 2.14 x86-64, 2.17 aarch64) — exactly the guard for the clock_gettime symver pin.
• TLS internal-buffer leak on handshake failure — false positive: on any handshake throw, state stays STATE_PLAINTEXT; JavaTlsClientSocket.close():141-145 explicitly frees the 3×256KB NATIVE_TLS_RSS buffers in that branch.
• setupIoWait() double-registration on reconnect — false positive: reconnect does socket.close() first, removing the fd from epoll before the re-ADD.
• connect_timeout==0 path change — false positive: both callers gate on >0 and otherwise call the unchanged connectAddrInfo; old behavior is byte-for-byte preserved.

Summary

• ~14 findings verified (0 critical, 2 moderate, ~12 minor); ~7 draft findings dropped as false positives or already-fixed.
• All verified findings are in-diff; the cross-context pass (every startTlsSession / connectAddrInfoTimeout / removed-facade-API / reconnect callsite) returned SAFE at every callsite — the large refactor has no broken external callers.
• Top asks before merge: M1 (flag the HTTP handshake timeout) and M2 (add a NOT_HANDSHAKING regression test + close the getBool / callback-exclusion / handshake-disconnect coverage gaps). Everything else is polish.
• Process: the title omits §5 (the riskiest part — the lease refactor and its concurrency fixes); surface it in the squash-merge message. Consider splitting the CI/native-build overhaul from the client changes for bisectability.

_{Generated by a level-3 multi-agent review; findings verified against source at 1570c5a.}

[mtopolnik]

[PR Coverage check]

😍 pass : 366 / 526 (69.58%)

file detail

	path	covered line	new line	coverage
🔵	io/questdb/client/impl/PooledSender.java	14	54	25.93%
🔵	io/questdb/client/impl/QueryLease.java	6	22	27.27%
🔵	io/questdb/client/cutlass/http/client/HttpClient.java	5	14	35.71%
🔵	io/questdb/client/network/JavaTlsClientSocket.java	17	46	36.96%
🔵	io/questdb/client/impl/QueryImpl.java	37	75	49.33%
🔵	io/questdb/client/impl/QuestDBImpl.java	3	5	60.00%
🔵	io/questdb/client/impl/ConfigView.java	5	8	62.50%
🔵	io/questdb/client/cutlass/http/client/WebSocketClient.java	12	18	66.67%
🔵	io/questdb/client/Sender.java	11	16	68.75%
🔵	io/questdb/client/impl/QueryClientPool.java	30	34	88.24%
🔵	io/questdb/client/cutlass/qwp/client/QwpQueryClient.java	12	13	92.31%
🔵	io/questdb/client/cutlass/qwp/client/sf/cursor/BackgroundDrainer.java	62	65	95.38%
🔵	io/questdb/client/impl/SenderSlot.java	19	20	95.00%
🔵	io/questdb/client/impl/QueryWorker.java	19	20	95.00%
🔵	io/questdb/client/QuestDBBuilder.java	47	48	97.92%
🔵	io/questdb/client/impl/SenderPool.java	37	38	97.37%
🔵	io/questdb/client/network/NetworkFacadeImpl.java	1	1	100.00%
🔵	io/questdb/client/HttpClientConfiguration.java	1	1	100.00%
🔵	io/questdb/client/impl/ConfigSchema.java	3	3	100.00%
🔵	io/questdb/client/cutlass/qwp/client/QwpWebSocketSender.java	20	20	100.00%
🔵	io/questdb/client/cutlass/qwp/client/sf/cursor/CursorWebSocketSendLoop.java	4	4	100.00%
🔵	io/questdb/client/SenderConnectionEvent.java	1	1	100.00%