sql: make forced close() resolve while a pool connection is mid-handshake

[robobun]

What does this PR do?

Fixes #32095. A forced pool close (sql.close({ timeout: "0" })) never resolved when a pool connection had been accepted at the TCP level but the database handshake had not completed yet (a database that is still starting up). The pending queries were rejected with ERR_POSTGRES_CONNECTION_CLOSED / ERR_MYSQL_CONNECTION_CLOSED, but the promise returned by close() stayed pending forever. With a nonzero connectionTimeout the close blocked until the connect timer fired (up to 30s by default); with connectionTimeout: 0 it hung forever.

import { SQL } from "bun";
import net from "node:net";

// server that accepts and never answers
const first = Promise.withResolvers<void>();
const server = net.createServer(() => first.resolve());
await new Promise<void>(r => server.listen(0, "127.0.0.1", r));
const port = (server.address() as net.AddressInfo).port;

const sql = new SQL({ url: `postgres://postgres@127.0.0.1:${port}/postgres`, max: 1, connectionTimeout: 0 });
const query = sql`SELECT 1`.catch(e => console.log("query rejected:", e.code));
await first.promise;

await sql.close({ timeout: "0" }); // never resolves
console.log("closed"); // never reached

Root cause

The pool's #close() resolves its per-connection promise from the onFinish hook, which only fires from the JS onClose/onConnected callbacks. For a mid-handshake connection those callbacks never came:

• uws does not dispatch on_close when an application closes a socket whose TCP connect has not resolved yet (POLL_TYPE_SEMI_SOCKET, see us_internal_socket_close_raw in packages/bun-usockets/src/socket.c), so closing an in-flight connect produces no event at all.
• postgres: disconnect() gated on Status::Connected, so a close during Connecting/SentStartupMessage did not touch the socket. The connect kept going and even sent the startup message after close() returned.
• mysql: do_close closed the socket unconditionally but got no event back for in-flight connects and never changed the status, so is_active() stayed true and kept the event loop referenced forever.
• mysql (js): the pool only stored the native handle in #onConnected, so connection.connection?.close() was a no-op for every pending connection.

The fix

• src/sql_jsc/postgres/PostgresSQLConnection.rs: close() now fails the connection directly when the status is Connecting/SentStartupMessage (outside VM shutdown). fail() consumes and fires the JS onclose callback, rejects pending queries, and closes whatever socket is live; since no socket event will do it, the poll ref is released explicitly. Shutdown paths and connected/terminal states keep going through disconnect() unchanged.
• src/sql_jsc/mysql/JSMySQLConnection.rs: do_close does the same for Connecting/Handshaking/Authenticating/AuthenticationAwaitingPk; connected/terminal states keep the existing clean_queue_and_close path.
• src/js/internal/sql/mysql.ts: #startConnection stores the native handle at creation (like the postgres adapter already did) so a forced close can reach it.
• src/js/internal/sql/postgres.ts + mysql.ts: if the pool is force-closed in the microtask window before the native handle is assigned, close the handle as soon as it materializes so onFinish settles.

fail() is idempotent (early-returns once the status is Failed), so the established-socket case, where closing does dispatch on_close synchronously, does not double-fire. The valkey client already works around the same uws behavior (src/runtime/valkey_jsc/valkey.rs close()), so this brings the SQL drivers in line; no other NsHandler consumer is affected.

How did you verify your code works?

test/js/sql/sql-close-pending-connection.test.ts (no docker needed): for each driver, a TCP server accepts and never answers, and the test asserts close({ timeout: "0" }) resolves, both while a connection is mid-handshake and when close is called before the native handle is stored. All four tests hang (5s timeout) on the unfixed build and pass with the fix.

Also verified:

• the issue's repro prints closed and the process exits on its own (no lingering poll ref), for both drivers
• with connectionTimeout: 2, forced close resolves in ~40ms instead of ~2s
• normal lifecycle against real postgres and mariadb servers (query, reserve, transaction, graceful close, forced close while connected, forced close with a query in flight, onconnect/onclose counts) is unchanged
• process exit while a connection is mid-handshake stays clean under the ASAN debug build
• test/js/sql/sql-connect-error-reporting.test.ts and test/js/sql/sql-onconnect-onclose-throw.test.ts still pass

[robobun]

^{Updated 12:56 AM PT - Jun 11th, 2026}

❌ @robobun, your commit 8fc74b1 has 5 failures in Build #61873 (All Failures):

• test/js/valkey/integration/complex-operations.test.ts - timeout on 🍎 14 aarch64
• test/js/sql/sql.test.ts - code 1 on 🍎 14 aarch64
• test/js/sql/sql-postgres-datetime-roundtrip.test.ts - code 1 on 🍎 14 aarch64
• test/js/bun/test/parallel/test-docker-build-distroless.ts - code 1 on 🍎 14 aarch64
• test/js/bun/test/parallel/test-docker-build-debian-slim.ts - code 1 on 🍎 14 aarch64

---

🧪   To try this PR locally:

bunx bun-pr 32097

That installs a local version of the PR into your bun-32097 executable, so you can run:

bun-32097 --bun

[coderabbitai]

Walkthrough

This PR fixes a bug where SQL.close() with zero timeout hangs indefinitely when a pooled connection is mid-handshake. Native connection close paths now fail in-flight connections immediately, and JS pooled wrappers explicitly close newly created connections if the pool was force-closed during creation. Comprehensive tests cover both Postgres and MySQL.

Changes

SQL pool forced close during handshake

Layer / File(s)	Summary
Native connection close handling for in-flight states src/sql_jsc/mysql/JSMySQLConnection.rs, src/sql_jsc/postgres/PostgresSQLConnection.rs	MySQL and Postgres close() methods now match on connection status and immediately fail connections (triggering onclose callbacks) if they are in Connecting, Handshaking, or Authenticating states, rather than waiting for socket close events that may never arrive.
JS pooled connection close handling src/js/internal/sql/mysql.ts, src/js/internal/sql/postgres.ts	#startConnection methods now detect whether the pool was force-closed (onFinish !== null) after the native handle is created and explicitly close that handle to ensure onFinish callbacks settle promptly.
Forced close mid-handshake test coverage test/js/sql/sql-close-pending-connection.test.ts	New parameterized test suite for Postgres and MySQL verifies SQL.close({ timeout: "0" }) resolves immediately during mid-handshake by simulating a TCP server that accepts but never completes the handshake, and validates driver-specific connection-closed error codes and proper resource cleanup.

Possibly related issues

• oven-sh/bun#32038: Addresses the same bug scenario—ensuring a forced/zero-timeout pool close tears down in-flight connections and settles onClose/onFinish callbacks.

Possibly related PRs

• oven-sh/bun#32027: Modifies handshake/connecting-time close and error handling in Postgres and MySQL connection implementations so in-flight failure scenarios map to correct error codes and callback settlement.
• oven-sh/bun#32028: Overlaps with pooled connection retry and shutdown-cancellation logic around intermediate connection states in the same pool/handshake lifecycle code.

Suggested reviewers

• alii
• cirospaciari

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: enabling forced close() to resolve when a pool connection is mid-handshake.
Description check	✅ Passed	The description fully covers both required template sections: clearly explains what the PR does and provides comprehensive verification steps.
Linked Issues check	✅ Passed	All code changes directly address the root causes identified in issue #32095: Postgres/MySQL connection close now properly fails mid-handshake states, native handles are stored earlier, and onFinish settles immediately [#32095].
Out of Scope Changes check	✅ Passed	All changes are scoped to fixing the mid-handshake close hang: Postgres/MySQL driver connection close logic, JS pool connection initialization, and a targeted test case.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/sql_jsc/mysql/JSMySQLConnection.rs`:
- Around line 709-711: The match arm that groups S::Connecting | S::Handshaking
| S::Authenticating | S::AuthenticationAwaitingPk should be split so only
S::Connecting calls fail() directly; for the post-on_open states (Handshaking,
Authenticating, AuthenticationAwaitingPk) explicitly drop the socket ref taken
by on_open before invoking fail() — e.g., invoke the same DerefOnDrop release
logic used in on_close (or call the code path that releases this.ref_()) so the
refcount goes down prior to clean_queue_and_close/ fail_with_js_value; update
the match to call fail() after releasing the ref for those three states to avoid
the semi-socket refcount leak.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 60c2d765-7ea0-4e0e-90c3-8e8c6f32d694

📥 Commits

Reviewing files that changed from the base of the PR and between f8723b1 and 8fc74b1.

📒 Files selected for processing (5)

• src/js/internal/sql/mysql.ts
• src/js/internal/sql/postgres.ts
• src/sql_jsc/mysql/JSMySQLConnection.rs
• src/sql_jsc/postgres/PostgresSQLConnection.rs
• test/js/sql/sql-close-pending-connection.test.ts

[cirospaciari]

good catch