CloudSQLInstance.close() calls socket.destroy(err) after connection pool drain, causing unhandled 'error' event and process crash

[MasahiroMorita]

CloudSQLInstance.close() calls socket.destroy(err) after connection pool drain, causing unhandled 'error' event and process crash

Environment

• @google-cloud/cloud-sql-connector: v1.11.0
• Node.js: 22.x
• Database driver: pg (node-postgres)

Description

When connector.close() is called after a pg connection pool has been fully drained via pool.end(), CloudSQLInstance.close() calls socket.destroy(new CloudSQLConnectorError({ code: 'ERRCLOSED', ... })) on each tracked socket. This triggers an 'error' event emission via process.nextTick. By that point, the pg driver has already removed its error listeners from the sockets as part of the pool shutdown, so the 'error' event fires with no listener — causing an uncaught exception that crashes the process.

Steps to Reproduce

1. Establish a Cloud SQL connection using the connector
2. Run a query through a pg.Pool
3. Call await pool.end() to drain the pool
4. Call connector.close() immediately after

Observed Behavior

CloudSQLConnectorError: The connector was closed.
at CloudSQLInstance.close (cloud-sql-instance.js:259:32)
at Connector.close (connector.js:252:32)
...

This error surfaces as an unhandled 'error' event on the socket (scheduled via process.nextTick inside socket.destroy(err)). In Node.js 15+, unhandled errors escalate to uncaughtException, causing the process to crash.

Expected Behavior

Calling connector.close() after pool.end() should not crash the process. Since the pool has already been drained and all connections cleanly terminated, there are no pending operations on the sockets. Destroying them as part of connector cleanup is correct, but emitting an error event to signal "The connector was closed" is unnecessary and harmful at this point.

Root Cause

In cloud-sql-instance.js, close() iterates over tracked sockets and calls:

socket.destroy(new errors_1.CloudSQLConnectorError({
    code: 'ERRCLOSED',
    message: 'The connector was closed.',
}));

socket.destroy(err) in Node.js schedules an 'error' event via process.nextTick. After pool.end() completes, the pg driver has already torn down its clients and detached error listeners from the underlying sockets. When the scheduled 'error' event fires in the next tick, no listener is present, resulting in an uncaught exception.

Suggested Fix

Call socket.destroy() without an error argument when close() is invoked intentionally, since passing an error is only meaningful when there are pending operations that need to be notified of an abnormal termination:

- socket.destroy(new errors_1.CloudSQLConnectorError({
-     code: 'ERRCLOSED',
-     message: 'The connector was closed.',
- }));
+ socket.destroy();

Alternatively, ensure the sockets have a no-op 'error' listener attached before calling destroy(err):

socket.once('error', () => {}); // prevent unhandled 'error' event
socket.destroy(new errors_1.CloudSQLConnectorError({ ... }));

Context

This was encountered when using firebase-tools v15.18.0, which calls connector.close() (without await) inside a cleanup function after pool.end() in connect.js. The race between the microtask queue resolving connector.close()'s internal operations and the already-drained pool's socket teardown triggers the issue consistently in CI environments running Node.js 22.

Workaround

Patching cloud-sql-instance.js to remove the error argument from socket.destroy() resolves the crash.

[ghasemel]

Confirming this from an independent reproduction.

Environment

• firebase-tools: 15.18.0 (also reproduces on 15.17.0)
• @google-cloud/cloud-sql-connector: 1.11.0 (resolved transitively via firebase-tools's ^1.3.3 range)
• Node.js: 24.16.0 (also reproduces on 25.8.1)
• Database driver: pg (via firebase-tools/lib/gcp/cloudsql/connect.js)
• Cloud SQL: Postgres 17.9 with IAM auth (cloudsql.iam_authentication=on)
• OS: macOS (Darwin 25.5.0)

Reproduction path
firebase deploy --only dataconnect --project <proj> reliably fails for me during setupSchemaIfNecessary → getSchemaMetadata → executeSqlCmdsAsIamUser. The IAM login completes, the very first SQL (SELECT pg_get_userbyid(nspowner) FROM pg_namespace WHERE nspname = 'public';) returns in ~13ms, and then the next-tick 'error' event from socket.destroy(err) propagates up before the result is returned. The CLI surfaces it as a generic Error: An unexpected error has occurred.

Bisect
I bisected @google-cloud/cloud-sql-connector against this failure with firebase-tools held constant:

version	result
1.3.4 — 1.6.1	works (no CloudSQLInstance.close() at all in 1.3.x–1.6.x; Connector.close() calls socket.destroy() with no argument)
1.7.0+	broken (introduced socket.destroy(new CloudSQLConnectorError(...)) inside CloudSQLInstance.close())

So 1.7.0 is the exact regression point. Newest known-good version is 1.6.1.

Workaround for firebase-tools users hitting this
Pin the transitive connector inside the global firebase-tools install:

cd $(npm root -g)/firebase-tools
npm install --no-save @google-cloud/cloud-sql-connector@1.6.1

After this, firebase deploy --only dataconnect completes normally and the schema-migration SQL runs against Cloud SQL as expected.

On the suggested fix
OP's proposal — calling socket.destroy() without the error argument when close() is invoked intentionally — restores 1.6.x behavior and is the minimal correct fix. The alternative (no-op 'error' listener before destroy(err)) also works but feels like papering over the root cause: passing an error to destroy() is meant to notify in-flight consumers of an abnormal termination, but by the time Connector.close() is called the sockets are already drained and there are no in-flight consumers to notify. Removing the argument matches the actual semantics.

[panavenue]

Hi @MasahiroMorita Thank you for reporting this issue.

I am wondering, do you know if this issue happens before current version v1.11.0?

@ghasemel Hi, thank you for the bisect. Just making sure, this issue was not introduced in recent release? I want to rule out the possibility if the issue comes from #566

[Deepak-0001-stack]

Hi @panavenue
I have reverted the version to v1.10.0 there am not seeing this error thrown when calling close () method, it started to work as earlier.

[panavenue]

Hi all, I just revert a change from last release, and created a new release which revert that change. Please try again with v1.11.1 to try again.

[MasahiroMorita]

@panavenue thanks for fixing this issue. this issue was suddenly happened when I update package.

[panavenue]

@MasahiroMorita No problem. Just wanted to confirm, is the issue fixed with the latest released version for you?

Another qq - What version were you using before the update?