[ShawnChen-Sirius]

Summary

Two workflows were red on main (commit 08ffdb2, the #52 merge). Both failures come from a lifecycle teardown racing an operation that the layer above assumes has already settled — fixed here in one change each.

Closes #53, closes #54.

#53 — test red: async-stress 120s hang on macos-14/Node-20

The closing a session while its async query is in flight (100x) case hung the full 120 s on macos-14/20.x, then the abandoned in-flight op poisoned 48 later v3 tests with Code: 236 … server is shutting down (ABORTED).

Root cause: a plain queryAsync (no signal/timeout) takes withAbortTimeout's fast path, which skipped trackNative. So pendingNativeOps was empty and Session.close() ran CloseConnection immediately, mid-flight. Releasing a connection while its query is still executing on the libuv worker aborts the in-process engine and, on some platforms, leaves the worker blocked inside chdb_query so its promise never settles → the caller's await hangs to the test timeout. (The test's own header comment predicted exactly this: "plain queryAsync is not tracked for drain".)

Fix: track every native async op (query and insert), not just the abort/timeout ones, so close() defers teardown until in-flight ops drain. This structurally removes the mid-flight-release race rather than papering over the timing.

#54 — connection red: unhandled ResultSet has been closed in parity

The parity job exited non-zero on 1 unhandled error even though all 27 test files passed:

⎯⎯ Uncaught Exception ⎯⎯
Error: ResultSet has been closed
 ❯ ResultSet.close packages/client-node/dist/result_set.js:244:30

Root cause: clickhouse-js's ResultSet.close() tears down via this._stream.destroy(new Error("ResultSet has been closed")). For a never-consumed result (the "format is not stream-able" test — stream() throws, then result.close() in its finally), nothing has attached an 'error' listener to the Readable we hand back, so Node escalates that synthetic teardown error to an uncaughtException. It surfaces asynchronously and vitest blames the next test (can pause response stream).

Fix: attach a benign 'error' listener to the materialized buffer Readable. That buffer has no genuine async error source (read() only ever pushes), so the only 'error' it can ever receive is exactly that external teardown signal — absorbing it makes close() idempotent as the upstream contract expects. Real consumers (Stream.pipeline in ResultSet.stream) attach their own error handler, so genuine errors still propagate. Also gitignores the parity runner's .chdb-runner checkout.

Verification

• v3 suite: 174 passed / 4 skipped; the lifecycle-race case is now ~2 s (was a 120 s hang).
• clickhouse-js parity runner (node tests/clickhouse-js/runner.mjs, clickhouse-js@main injected with ChdbConnection): exits 0 with 0 unhandled errors — Test Files 27 passed | 2 skipped, Tests 180 passed | 41 skipped.

Note: #53's hang is macos-14/Node-20 timing-sensitive and could not be reproduced on the dev box's newer Node; the fix is structural (no longer releases a connection with an in-flight op) and does not depend on timing. Final confirmation is the CI leg itself.

🤖 Generated with Claude Code