[robobun]

Fixes #32096

Repro

const sql = new Bun.SQL(url, { max: 1 });
const query = sql`select pg_sleep(2)`.catch(e => e.code);
await Bun.sleep(100);
await sql.close({ timeout: 2 ** 31 }); // resolves after ~1 ms
console.log(await query);              // ERR_POSTGRES_CONNECTION_CLOSED

TimeoutOverflowWarning: 2147483648000 does not fit into a 32-bit signed integer.
Timeout duration was set to 1.

Cause

close({ timeout }) takes seconds, but every close site (the pool close shared by the postgres and mysql adapters, reserved_sql.close, transaction_sql.close) validated the upper bound against the seconds value and then armed the timer in milliseconds:

if (timeout > 2 ** 31 || timeout < 0 || timeout !== timeout) { throw ... }
...
setTimeout(..., timeout * 1000);

setTimeout clamps delays above 2 ** 31 - 1 ms to 1 ms, so any timeout in (2147483.647, 2 ** 31] seconds passed validation and force-closed after about 1 ms, cancelling in-flight queries instead of waiting.

Fix

• One shared validateTimeoutSeconds(name, value) in internal/sql/shared.ts, bounded at (2 ** 31 - 1) / 1000 seconds, replaces the inline checks. It also covers the idle_timeout, connection_timeout and max_lifetime constructor options, which had the same seconds-bounded check before their own * 1000; their native consumer saturates at 2 ** 31 - 1 ms, so out of range values silently became 24.8 days. The error message now states the real bound: must be a non-negative number no greater than 2147483.647 seconds. After the rebase onto sql: consolidate JS pool/connection plumbing into BasePooledConnection in shared.ts #32145 (which consolidated the postgres and mysql adapters' pool plumbing into shared.ts), that means the consolidated pool close() in shared.ts plus reserved_sql.close and transaction_sql.close in sql.ts.
• In reserved_sql.close and transaction_sql.close, validation ran after acceptQueries was already cleared, so a rejected close left the handle refusing all further queries. Validation now runs before the state mutation. Main has since given the pool close() the same shape (a hasTimeout flag checked before closed = true), and this PR drops the validator into that block.

While verifying the reserved path I hit an unrelated pre-existing hang (reserved.close() then sql.close() never resolves, with no timeout option at all); filed as #32099, not touched here.

Verification

test/js/sql/sql-close-timeout-overflow.test.ts:

• idle_timeout, connection_timeout and max_lifetime reject 2 ** 31, 2147483.648, and Infinity in the constructor and accept the exact max, 60, and 0.
• postgres and mysql pool close() reject 2 ** 31, 2147483.648, and Infinity with ERR_INVALID_ARG_VALUE, accept 2147483.647 (the exact max), 60, and 0.5, and still reject -1 and non-numeric input. Pool connections are lazy, so these run without a server.
• sqlite transaction: tx.close({ timeout: 2 ** 31 }) rejects and the transaction still runs queries and commits.
• reserved connection (docker-gated, postgres): the rejected close leaves the connection usable and releasable.

The server-free tests fail on the unfixed build (13 fail: the close resolves instead of rejecting, and the sqlite transaction gets rolled back with ERR_SQLITE_CONNECTION_CLOSED) and pass with the fix (37 pass). Re-verified after each rebase (onto #32145, and again onto current main at ae3c3ad).

The new test file is separate from sql.test.ts because that file is wrapped in isDockerEnabled() and skips entirely without docker; these tests need no server.

---

[human-review] gate passed · iteration 5 · 3 files touched

fails on main (without fix)

ASAN without fix: 13 FAILED
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test "--reporter=junit" "--reporter-outfile=/tmp/pr_gate.xml" test/js/sql/sql-close-timeout-overflow.test.ts
bun test v1.4.3 (f42e98025)

test/js/sql/sql-close-timeout-overflow.test.ts:
30 |       await using sql = new SQL(url, { max: 1 });
31 |       const err = await sql.close({ timeout }).then(
32 |         () => null,
33 |         e => e,
34 |       );
35 |       expect(err?.code).toBe("ERR_INVALID_ARG_VALUE");
                             ^
error: expect(received).toBe(expected)

Expected: "ERR_INVALID_ARG_VALUE"
Received: undefined

      at <anonymous> (/workspace/bun/test/js/sql/sql-close-timeout-overflow.test.ts:35:25)
(fail) postgres: close() rejects timeout 2147483648, whose millisecond value overflows setTimeout [183.99ms]
30 |       await using sql = new SQL(url, { max: 1 });
31 |       const err = await sql.close({ timeout }).then(
32 |         () => null,
33 |         e => e,
34 |       );
35 |       expect(err?.code).toBe("ERR_INVALID_ARG_VALUE");
                             ^
error: expect(received).toBe(expected)

Expected: "ERR_INVALID_ARG_VALUE"
Received: undefined

      at <
... (truncated)

release without fix: 13 FAILED
bun test v1.4.3-canary.1 (f42e98025)

test/js/sql/sql-close-timeout-overflow.test.ts:
30 |       await using sql = new SQL(url, { max: 1 });
31 |       const err = await sql.close({ timeout }).then(
32 |         () => null,
33 |         e => e,
34 |       );
35 |       expect(err?.code).toBe("ERR_INVALID_ARG_VALUE");
                             ^
error: expect(received).toBe(expected)

Expected: "ERR_INVALID_ARG_VALUE"
Received: undefined

      at <anonymous> (/workspace/bun/test/js/sql/sql-close-timeout-overflow.test.ts:35:25)
(fail) postgres: close() rejects timeout 2147483648, whose millisecond value overflows setTimeout [2.66ms]
30 |       await using sql = new SQL(url, { max: 1 });
31 |       const err = await sql.close({ timeout }).then(
32 |         () => null,
33 |         e => e,
34 |       );
35 |       expect(err?.code).toBe("ERR_INVALID_ARG_VALUE");
                             ^
error: expect(received).toBe(expected)

Expected: "ERR_INVALID_ARG_VALUE"
Received: undefined

      at <anonymous> (/workspace/bun/test/js/sql/sql-close-timeout-overflow.test.ts:35:25)
(fail) postgres: close() rejects timeout 2147483.648, whose millisecond value overflows set
... (truncated)

passes on PR (with fix)

ASAN with fix: all passed
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test "--reporter=junit" "--reporter-outfile=/tmp/pr_gate.xml" test/js/sql/sql-close-timeout-overflow.test.ts
bun test v1.4.3 (f42e98025)

test/js/sql/sql-close-timeout-overflow.test.ts:
(pass) postgres: close() rejects timeout 2147483648, whose millisecond value overflows setTimeout [127.87ms]
(pass) postgres: close() rejects timeout 2147483.648, whose millisecond value overflows setTimeout [6.42ms]
(pass) postgres: close() rejects timeout Infinity, whose millisecond value overflows setTimeout [4.71ms]
(pass) postgres: close() accepts timeout 2147483.647 [11.36ms]
(pass) postgres: close() accepts timeout 60 [3.73ms]
(pass) postgres: close() accepts timeout 0.5 [3.79ms]
(pass) postgres: close() still rejects timeout -1 [15.14ms]
(pass) postgres: close() still rejects timeout "not a number" [4.78ms]
(pass) mysql: close() rejects timeout 2147483648, whose millisecond value overflows setTimeout [8.23ms]
(pass) mysql: close() rejects timeout 2147483.648, whose millisecond value overflows setTimeout [4.34ms]
(pass) mysql: close() rejects timeout Infinity, whose millisecond value overflows setTimeout [4.
... (truncated)

release with fix: all passed
$ bun scripts/build.ts --profile=release
[configured] bun-profile → bun (stripped) in 890ms (unchanged)
ninja: Entering directory `/workspace/bun/build/release'
[1/21] gen JS modules (bundle-modules)
Preprocess modules (9006ms)
Bundle modules (80ms)
Postprocesss modules (37ms)
Bundle Functions (633ms)
Generate Code (44ms)

[9.81s] Bundled "src/js" for production
  2594 kb
  197 internal modules
  13 native modules
  50 internal functions across 16 files
[1/5] cargo bun_runtime → libbun_runtime.a
�[1m�[92m   Compiling�[0m bun_js_printer v0.0.0 (/workspace/bun/src/js_printer)
�[1m�[92m   Compiling�[0m bun_bundler v0.0.0 (/workspace/bun/src/bundler)
�[1m�[92m   Compiling�[0m bun_standalone_graph v0.0.0 (/workspace/bun/src/standalone_graph)
�[1m�[92m   Compiling�[0m bun_transpiler v0.0.0 (/workspace/bun/src/transpiler)
�[1m�[92m   Compiling�[0m bun_bunfig v0.0.0 (/workspace/bun/src/bunfig)
�[1m�[92m   Compiling�[0m bun_install v0.0.0 (/workspace/bun/src/install)
�[1m�[92m   Compiling�[0m bun_jsc v0.0.0 (/workspace/bun/src/jsc)
�[1m�[92m   Compiling�[0m bun_js_parser_jsc v0.0.0 (/workspace/bun/src/js_parser_jsc)
�[1m�[92m   Compiling�[0m bun_bundler_jsc v0.0.0 (/work
... (truncated)

diff hotspot

src/js/bun/sql.ts                              |  21 ++--
 src/js/internal/sql/shared.ts                  |  53 ++++------
 test/js/sql/sql-close-timeout-overflow.test.ts | 133 +++++++++++++++++++++++++
 3 files changed, 164 insertions(+), 43 deletions(-)

gate history · 1 passed · 0 rejected · iteration 5

evidence per changed file

file                                            reads  edits  tests
src/js/bun/sql.ts                                   3      5     32
src/js/internal/sql/shared.ts                       7     10     28
test/js/sql/sql-close-timeout-overflow.test.ts      3      9     28

root cause · written by the author bot

The timeout validation in the SQL close paths and constructor options compared the raw seconds value against 2 ** 31, but the timer was armed with timeout * 1000 milliseconds, so any value between roughly 2147483.648 and 2 ** 31 seconds passed validation and then overflowed setTimeout's 32-bit delay, which clamped it to 1 ms and force-closed the pool almost immediately. The fix introduces a shared validateTimeoutSeconds helper that bounds the seconds value against (2 ** 31 - 1) / 1000 so the millisecond product can never overflow, and routes all six inline checks through it. It also moves v…

[robobun]

^{Updated 1:05 AM PT - Sep 8th, 2026}

❌ @robobun, your commit 9bf4cf6 has 1 failures in Build #112511 (All Failures):

• test/js/node/test/parallel/test-crypto-dh-leak.js - code 1 on 🐧 13 x64-asan

---

🧪   To try this PR locally:

bunx bun-pr 32100

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

bun-32100 --bun

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Essentials

Run ID: ea9b7838-9d1d-482a-a7eb-81be6a75adb5

📥 Commits

Reviewing files that changed from the base of the PR and between b52d3e5 and 9bf4cf6.

📒 Files selected for processing (3)

• src/js/bun/sql.ts
• src/js/internal/sql/shared.ts
• test/js/sql/sql-close-timeout-overflow.test.ts

Included review availability: Your plan provides up to 10 included reviews per hour; 1 remains after this review.

---

Walkthrough

Adds shared seconds-based timeout validation for SQL pools, reserved connections, transactions, and constructor timeout options. Validation now occurs before millisecond conversion and close-state changes. Tests cover overflow, boundaries, invalid values, exact errors, and continued connection usability.

Changes

SQL timeout validation

Layer / File(s)	Summary
Shared timeout validator src/js/internal/sql/shared.ts	Adds MAX_TIMER_MS, MAX_TIMEOUT_SECONDS, and validateTimeoutSeconds. The helper rejects negative, NaN, and timer-overflowing values, then exports through the shared module.
SQL timeout integration src/js/bun/sql.ts, src/js/internal/sql/shared.ts	Pool, reserved-connection, and transaction close paths use shared validation before state changes. Constructor timeout options use the same validation before conversion to milliseconds.
Overflow and state-preservation tests test/js/sql/sql-close-timeout-overflow.test.ts	Tests cover overflow, boundary, valid, and legacy-invalid values. They also verify the exact error message and continued SQLite transaction and Postgres reserved-connection usability after rejection.

Severity of issue fixed: Medium

Merge Risk: ⚪ Minimal · up to 9bf4c

SQL timeout options now reject values that would overflow timer milliseconds, preventing premature connection closure while preserving valid boundary behavior. The covered pool, reserved connection, transaction, and constructor paths are ready to merge.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The changes satisfy issue #32096 by applying the corrected millisecond-safe bound to pool, reserved connection, and transaction close timeouts. Validation occurs before state mutation where required, …
Out of Scope Changes check	✅ Passed	The additional validation for idle_timeout, connection_timeout, and max_lifetime addresses the same seconds-to-milliseconds overflow defect and remains related to the linked issue's objective. No unre…
Description check	✅ Passed	The description explains the problem, root cause, implementation, scope, regression coverage, and verification results. It does not use the exact template headings, but it provides the information req…
Title check	✅ Passed	The title is concise and accurately identifies the primary change: rejecting SQL close timeouts that exceed setTimeout's millisecond range.

---

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

[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 `@test/js/sql/sql-close-timeout-overflow.test.ts`:
- Around line 103-112: The test leaks the reserved connection if an assertion
fails because reserved.release() is called after assertions; wrap the test body
that performs assertions and queries in a try/finally (or register cleanup) so
reserved.release() runs on every exit path. Specifically, after obtaining the
connection via sql.reserve() and performing the reserved.close() call/assertions
and the subsequent reserved`select 1 as x` check, ensure reserved.release() is
placed inside a finally block (or registered before assertions) so it always
executes even when expect() throws.

🪄 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: 73ecfc54-3067-42f2-8da5-d1957fe3d6ac

📥 Commits

Reviewing files that changed from the base of the PR and between f8723b1 and 33c9204.

📒 Files selected for processing (5)

• src/js/bun/sql.ts
• src/js/internal/sql/mysql.ts
• src/js/internal/sql/postgres.ts
• src/js/internal/sql/shared.ts
• test/js/sql/sql-close-timeout-overflow.test.ts

[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/js/internal/sql/shared.ts`:
- Around line 1222-1248: The timeout branch is incorrectly gated by truthiness
so a provided timeout of 0 is treated as "no timeout"; update the check to
detect presence (e.g., options?.timeout !== undefined) so that timeout =
validateCloseTimeout(timeout) is used for zero and the immediate-close behavior
(this.closed = true; if (timeout === 0 || !this.hasPendingQueries()) { await
this.#close(); return; }) runs; ensure the rest of the timeout flow
(Promise.withResolvers, setTimeout using timeout * 1000, timer.unref(),
this.onAllQueriesFinished clearing timer and calling
this.#close().finally(resolve)) remains unchanged.

🪄 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: b8d90858-952d-473d-8e46-8e1d73956e0a

📥 Commits

Reviewing files that changed from the base of the PR and between d5e4b90 and 3b87de4.

📒 Files selected for processing (3)

• src/js/bun/sql.ts
• src/js/internal/sql/shared.ts
• test/js/sql/sql-close-timeout-overflow.test.ts

[coderabbitai]

Caution

Inline review comments failed to post. This is likely due to GitHub's internal server error or limits when posting large numbers of comments. If you are seeing this consistently it is likely a permissions issue. Please check "Moderation" -> "Code review limits" under your organization settings.

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/js/internal/sql/shared.ts`:
- Around line 1222-1248: The timeout branch is incorrectly gated by truthiness
so a provided timeout of 0 is treated as "no timeout"; update the check to
detect presence (e.g., options?.timeout !== undefined) so that timeout =
validateCloseTimeout(timeout) is used for zero and the immediate-close behavior
(this.closed = true; if (timeout === 0 || !this.hasPendingQueries()) { await
this.#close(); return; }) runs; ensure the rest of the timeout flow
(Promise.withResolvers, setTimeout using timeout * 1000, timer.unref(),
this.onAllQueriesFinished clearing timer and calling
this.#close().finally(resolve)) remains unchanged.

🪄 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: b8d90858-952d-473d-8e46-8e1d73956e0a

📥 Commits

Reviewing files that changed from the base of the PR and between d5e4b90 and 3b87de4.

📒 Files selected for processing (3)

• src/js/bun/sql.ts
• src/js/internal/sql/shared.ts
• test/js/sql/sql-close-timeout-overflow.test.ts

🛑 Comments failed to post (1)

src/js/internal/sql/shared.ts (1)

1222-1248: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Handle timeout: 0 by presence, not truthiness.

Line 1223 and Line 1247 both gate on if (timeout), so sql.close({ timeout: 0 }) never enters the timeout path and does not take the intended immediate-close branch. That leaves 0 behaving like “no timeout provided” instead of “force close now”.

💡 Suggested fix

   async close(options?: { timeout?: number }): Promise<void> {
     if (this.closed) {
       return;
     }
 
     let timeout = options?.timeout;
-    if (timeout) {
+    const hasTimeout = timeout === 0 || !!timeout;
+    if (hasTimeout) {
       timeout = validateCloseTimeout(timeout);
 
       this.closed = true;
       if (timeout === 0 || !this.hasPendingQueries()) {
         // close immediately
@@
 
       return promise;
     } else {
       this.closed = true;
       if (!this.hasPendingQueries()) {

🤖 Prompt for 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.

In `@src/js/internal/sql/shared.ts` around lines 1222 - 1248, The timeout branch
is incorrectly gated by truthiness so a provided timeout of 0 is treated as "no
timeout"; update the check to detect presence (e.g., options?.timeout !==
undefined) so that timeout = validateCloseTimeout(timeout) is used for zero and
the immediate-close behavior (this.closed = true; if (timeout === 0 ||
!this.hasPendingQueries()) { await this.#close(); return; }) runs; ensure the
rest of the timeout flow (Promise.withResolvers, setTimeout using timeout *
1000, timer.unref(), this.onAllQueriesFinished clearing timer and calling
this.#close().finally(resolve)) remains unchanged.

[robobun]

Re the latest CodeRabbit finding on the timeout truthiness gate in shared.ts close(): that behavior is pre-existing, this PR only replaces the bound check inside the branch. close({ timeout: 0 }) being treated as "no timeout" is tracked in #32038 and has a dedicated fix open in #32039, so changing it here would be an out of scope behavior change that conflicts with that PR.

[claude]

LGTM — focused validation fix with thorough test coverage.

Extended reasoning...

Overview

This PR fixes a timeout-overflow bug in sql.close({ timeout }): the option is in seconds, but the deadline timer is armed in milliseconds, and the old upper-bound check (> 2 ** 31 seconds) allowed values whose millisecond product overflows setTimeout's 32-bit limit and gets clamped to 1 ms. The fix consolidates three identical inline checks into a shared validateCloseTimeout helper bounded at (2 ** 31 - 1) / 1000 seconds, and reorders validation in reserved_sql.close / transaction_sql.close to run before clearing acceptQueries, so a rejected close no longer poisons the handle. A new test file covers rejection of overflowing values, acceptance of the exact boundary, continued rejection of previously-invalid inputs, and the validate-before-mutate ordering across postgres/mysql/sqlite/reserved paths.

Security risks

None. This is input validation tightening on a numeric timeout option; no auth, crypto, network, or untrusted-input parsing is involved.

Level of scrutiny

Low-to-moderate. The change is small (~30 source lines), mechanical, and follows the existing validation pattern used for idleTimeout / connectionTimeout / maxLifetime in the same file. The only behavior changes are (1) rejecting timeouts in (2147483.647, 2^31] seconds that were previously accepted-but-broken, and (2) a more accurate error message — both strict improvements with no realistic compatibility impact.

Other factors

• The bug-hunting system found no issues.
• CodeRabbit's only comment (release the reserved connection on assertion failure) was addressed via await using and confirmed resolved.
• No CODEOWNERS apply to these paths.
• The reordering preserves semantics: validateCloseTimeout throws inside async functions, so callers still see a rejected promise; the split if (timeout) { validate } … if (timeout) { use } is equivalent to the prior single block for all inputs (0, falsy, truthy, string-coercible).
• Test coverage is well-designed: pool tests need no server (lazy connect), the sqlite transaction path runs in-process, and only the reserved-connection test is docker-gated.

[claude]

LGTM — focused fix that corrects the seconds-vs-milliseconds bound and moves validation ahead of state mutation, with thorough test coverage.

Extended reasoning...

Overview

This PR fixes #32096: sql.close({ timeout }) validated the upper bound against the seconds value (2 ** 31) but then passed timeout * 1000 to setTimeout, so values in (2147483.647, 2 ** 31] seconds overflowed the 32-bit ms range and were clamped to 1 ms, force-closing immediately. The fix introduces a shared validateCloseTimeout in internal/sql/shared.ts bounded at (2 ** 31 - 1) / 1000 seconds and replaces the three inline checks (pool close in shared.ts, reserved_sql.close and transaction_sql.close in sql.ts). It also reorders the reserved/transaction close paths so validation runs before clearing acceptQueries, so a rejected close no longer leaves the handle unusable. A new test file covers overflow rejection, boundary acceptance, the error message, and post-rejection usability for sqlite transactions and (docker-gated) postgres reserved connections.

Security risks

None. This is pure input-validation tightening on a numeric option in JS-land; no auth, crypto, parsing of untrusted data, or native code is touched. The only behavior change is that previously-accepted absurdly large timeouts now reject with ERR_INVALID_ARG_VALUE instead of silently misbehaving.

Level of scrutiny

Low-to-moderate. The production diff is ~30 lines: a 10-line helper plus three call-site substitutions and two statement reorderings. The bound math ((2 ** 31 - 1) / 1000) is correct for setTimeout's documented limit, and the reordering is a clear improvement (validate-then-mutate). The split into two if (timeout) blocks preserves the existing control flow exactly aside from where the throw lands relative to the state flip.

Other factors

• No CODEOWNERS for these paths.
• The bug-hunting system found nothing.
• The one CodeRabbit finding (reserved-connection cleanup on assertion failure) was addressed via await using and confirmed resolved.
• The author explicitly scoped out the pre-existing timeout: 0 truthiness quirk (#32038/#32039) and the unrelated reserved-close hang (#32099), keeping this change minimal.
• Tests verify both the new rejection boundary and that previously-rejected inputs (-1, non-numeric) stay rejected, and were reported passing on the fixed build and failing on the unfixed one.

[robobun]

CI status: every lane that ran is green (284 jobs, including the ASAN lane). The only outstanding check is darwin-14-aarch64-test-bun, which has expired twice waiting for an agent and is requeued; the red check is queue starvation on that lane, not a test failure. The diff is ready for review.

[robobun]

Stale PR review: keep open, rework.

The bug in #32096 is still on main. All three close() sites check timeout > 2 ** 31 in seconds and then arm setTimeout(..., timeout * 1000): src/js/internal/sql/shared.ts:1310 and :1329, and src/js/bun/sql.ts:477 and :494 (reserved) and :761 and :780 (transaction). The reserved and transaction paths also clear acceptQueries (sql.ts:473 and :756) before they validate, so a rejected close() leaves the handle unusable. No other open PR fixes either problem. #39617, #32149, and #33740 all carry timeout * 1000 forward unchanged.

The diff is not the shape that would land. It conflicts with main's hasTimeout refactor, and the three sibling PRs above are mergeable and rewrite the same hunks, so it would conflict again after they land. It replaces the existing error text with a new one (must be a non-negative number no greater than 2147483.647 seconds) that the test pins byte for byte. It adds a 115-line docker-gated test file where test/js/sql/sql-helpers-validation.test.ts already has the adapter matrix.

The shape that would be wanted: wait for #39617, #32149, and #33740 to land. Then one shared helper in shared.ts, bounded at (2 ** 31 - 1) / 1000, called from BaseSQLAdapter.close inside the hasTimeout block and from the reserved and transaction close() above the acceptQueries clear. Keep the ERR_INVALID_ARG_VALUE throw and the existing message register. Add the cases as test.each rows in sql-helpers-validation.test.ts.

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

Additional findings (outside the current diff — GitHub can't attach inline comments there):

• 🟣 src/js/internal/sql/shared.ts — Pre-existing: the same seconds-bounded-at-231-then-×1000 defect this PR fixes for close({ timeout }) remains at three sibling sites in the same file — idleTimeout (2089), connectionTimeout (2101), maxLifetime (2113) each check the seconds value against 2 ** 31 and then *= 1000, so values in (2147483.647, 231] pass validation and overflow the millisecond consumer just like the close() bug. REVIEW.md requires fixing the whole class in the same PR. Fix: bound all seconds→ms options at (2**31 - 1)/1000 via one shared helper (parameterize the option name), or state in the PR why these sites are excluded.

  Extended reasoning...

  parseOptions in shared.ts validates idleTimeout/connectionTimeout/maxLifetime with if (v > 2 ** 31 || v < 0 || v !== v) and then does v *= 1000 (lines 2096/2108/2120). A user passing e.g. idle_timeout: 3_000_000 (seconds) passes validation and yields 3_000_000_000 ms, which overflows the 32-bit millisecond range the downstream timers use — the identical mechanism the PR describes and fixes for close({ timeout }). The PR extracts validateCloseTimeout into this file but applies it only to the three close() call sites; the PR description does not mention excluding these siblings. Per REVIEW.md "Fix the whole class in the same PR — grep for every sibling site sharing the pattern; if a site is intentionally excluded, say so in the PR", this is in scope. Marked pre-existing because the base branch already has the wrong bound at these three sites.

  Verification: pre-existing — the base branch already has the identical defect at these three sites and this PR does not touch them, so merging makes nothing worse; flagged under REVIEW.md's "Fix the whole class in the same PR". The three sibling sites in /home/claude/bun/src/js/internal/sql/shared.ts share the exact seconds-bounded-then-×1000 pattern this PR fixes for close(): - Line 2089: `if (idleTimeout…

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

Beyond the inline finding: commit 01b187f added constructor tests for idle_timeout / connection_timeout / max_lifetime rejecting 2 ** 31 and 2147483.648, but only touched the test file — parseOptions in src/js/internal/sql/shared.ts (lines ~2087–2121) still validates those three options against > 2 ** 31 before the *= 1000. Six of the new constructor tests will fail as-is; the shared validator (or an equivalent bound) needs to be applied there too.

Extended reasoning...

The "What changed" summary flagged that the diff shows no change to parseOptions for the constructor timeout options, and asked to verify. I checked: the latest commit's message says it bounds idle_timeout, connection_timeout, and max_lifetime by their millisecond product, but git show 01b187f2 --stat shows it modified only the test file. The current parseOptions still uses if (idleTimeout > 2 ** 31 || ...) for all three options, so the newly added test.each([2 ** 31, 2147483.648, Infinity]) constructor-rejection cases will fail for the first two values on each option. This is a concrete gap not covered by the posted inline finding, so it's worth surfacing in the review body rather than staying silent.

[coderabbitai]

Note

GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer.

[robobun]

Rebased onto main at ae3c3ad. One conflict in shared.ts: main had restructured the pool close() around a hasTimeout flag that already runs validation before closed = true, so the validator now sits inside that block. The dead code passes on main had also dropped buildDefinedColumnsAndQuery and normalizeSSLMode from the export list, which I kept dropped.

On the sibling sites: the review was right that idle_timeout, connection_timeout and max_lifetime carried the same seconds-bounded check before their own * 1000. Traced the consumer: createConnection reads them with to_int32(), which saturates, so those options silently clamped to 24.8 days instead of rejecting. 6a48937 generalizes the helper to validateTimeoutSeconds(name, value) and applies it to all seven seconds-to-milliseconds sites (the three close() paths plus the three constructor options). The only remaining 2 ** 31 check is options.max, a connection count, which is correct as is.

01b187f shipped those constructor tests without the matching src change; that is why test/js/sql/sql-close-timeout-overflow.test.ts went red on build 112360. 6a48937 has the src. Verified on this tree: 37 pass with the fix, 13 fail against main src.

[claude]

LGTM — the isDockerEnabled() wrapper is gone and describeWithContainer now decides for itself, which was the last thing I'd flagged.

Checked: the new MAX_TIMEOUT_SECONDS bound ((2**31 - 1) / 1000) is exact for every * 1000 site it feeds; validation now runs before acceptQueries is cleared in both reserved_sql.close and transaction_sql.close, and the pool close() in shared.ts already had hasTimeout gated before this.closed = true; all six former inline checks route through the one helper with the same $ERR_INVALID_ARG_VALUE code. Tests pin the boundary at 2147483.647 / 2147483.648, keep -1 and non-numeric rejected, and assert the reserved/transaction handle still runs queries after a rejected close.

Extended reasoning...

Overview

The PR replaces six duplicated inline timeout > 2 ** 31 || timeout < 0 || timeout !== timeout checks (three close({timeout}) variants plus idle_timeout/connection_timeout/max_lifetime in parseOptions) with a single validateTimeoutSeconds() helper in src/js/internal/sql/shared.ts that bounds against (2 ** 31 - 1) / 1000 seconds so the subsequent * 1000 cannot exceed setTimeout's 32-bit millisecond ceiling. In src/js/bun/sql.ts the reserved-connection and transaction close() paths are reordered so the validator throws before state.connectionState &= ~ReservedConnectionState.acceptQueries, fixing the "rejected close leaves the handle unusable" side effect. A new test file covers the overflow boundary, the exact upper bound, still-rejected inputs, the error message text, and the stays-usable behavior across pool/reserved/transaction and postgres/mysql/sqlite.

Security risks

None. This is input validation on a numeric option that only affects when a locally-armed timer fires. No auth, crypto, network parsing, or filesystem paths are touched. The change tightens validation (values that previously silently misbehaved now throw ERR_INVALID_ARG_VALUE), which is the safer direction.

Level of scrutiny

Low-to-moderate. It is a small, mechanical consolidation of duplicated validation into a shared helper — exactly the shape REVIEW.md's "fix the whole class" rule asks for — plus a two-line reordering to move validation ahead of a state mutation. The arithmetic is straightforward and the helper preserves the existing $ERR_INVALID_ARG_VALUE error code, so callers that catch on .code are unaffected; only the message text changes, and it now states the real bound. No CODEOWNERS entry covers src/js/bun/sql.ts or src/js/internal/sql/.

Other factors

This is my third look at the PR. The only concern I'd previously raised — an if (isDockerEnabled()) guard around describeWithContainer that would have silently skipped the reserved-connection test on Linux arm64 CI lanes served by the docker coordinator — was addressed in commit 9bf4cf6, which drops the guard and lets describeWithContainer handle availability itself. There are no outstanding CHANGES_REQUESTED reviews from other reviewers (only bot COMMENTED states), and the bug hunt exited on dry_streak with no findings. The PR description's justification for a separate test file (the existing sql.test.ts is entirely gated on isDockerEnabled() while most of these tests need no server) is reasonable given the harness constraints.

[robobun]

CI on 9bf4cf6 (build 112511): 178 jobs green, including the sql test file on every lane that has finished. The one red job is debian x64-asan, where the only failure is test/js/node/test/parallel/test-crypto-dh-leak.js, an RSS assertion in node:crypto that is red on main too and is already reported for triage. The remaining darwin x64 test jobs are still queued after expiring three times waiting for an agent. Nothing here touches this change; the diff is ready for review.

[Jarred-Sumner]

close({ timeout }) is validated in seconds and armed in milliseconds, so anything in (2147483.647, 2 ** 31] seconds became a 1 ms timer and killed the queries it was meant to wait for. #45304 fixes that by clamping the delay, not by rejecting the value.

closeTimeoutMs() in src/js/internal/sql/pool.ts keeps main's validation and returns Math.min(seconds * 1000, 2 ** 31 - 1). sql.close(), reserved.close() and tx.close() all go through it. close({ timeout: 2 ** 31 }) with a query in flight now waits for the query and prints no TimeoutOverflowWarning.

The stricter bound is not in, and in particular not for idleTimeout, connectionTimeout and maxLifetime. maxLifetime: 60 * 60 * 24 * 30 works on main, because the native timer saturates instead of wrapping. With this change it would throw in the constructor.

The second half is in as proposed: reserved.close() and tx.close() validate before they touch any state, so a rejected close({ timeout: -1 }) leaves the handle usable.

See "close({ timeout: 2 ** 31 }) waits for the query" and "close({ timeout: %p }) rejects and the pool stays open" (-1, NaN, "soon", 2 ** 31 + 1) in test/js/sql/sql-pool.test.ts, and "close() with an invalid timeout throws and leaves the handle as it was" in test/js/sql/sql-handles.test.ts. Infinity still rejects. This fixes #32096. #32099, which was filed from here, did not reproduce on current main.