sql(postgres): decode float8/float4 text 'Infinity'/'-Infinity' as ±Infinity, not NaN

[robobun]

Fixes #39777.

What does this PR do?

Postgres emits the literal tokens Infinity / -Infinity / NaN for float8 and float4 columns in text format (float8out in src/backend/utils/adt/float.c). The scalar text decoder parsed these with WTF::parseDouble, which follows JS-number grammar and rejects those tokens, so the .unwrap_or(f64::NAN) fallback silently turned every ±Infinity into NaN.

The float8[] array text decoder already special-cased the same tokens, so the same wire value decoded as NaN in a scalar column and Infinity inside an array:

const [row] = await sql`select 'infinity'::float8 as a, '{infinity}'::float8[] as b`;
row.a   // NaN      (wrong)
row.b   // [Infinity]  (correct)

Fix

Switch the scalar float8/float4 text path from bun_core::parse_double to bun_core::fmt::parse_f64, which wraps WTF::parseDouble and adds the inf/infinity/nan arms the array path already has.

How did you verify your code works?

New test test/js/sql/postgres-float-infinity.test.ts drives a scripted simple-query backend that sends text-format Infinity / -Infinity / NaN / 1.5 in float8 and float4 columns. Fails on main (Expected: Infinity, Received: NaN), passes with this change. Also pins the already-correct float8[] array behaviour so the two paths stay consistent.

---

[review] gate passed · iteration 8 · 2 files touched

fails on main (without fix)

ASAN without fix: 2 FAILED
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test "--reporter=junit" "--reporter-outfile=/tmp/mechgate.xml" test/js/sql/postgres-float-infinity.test.ts
bun test v1.4.0 (410458502)

test/js/sql/postgres-float-infinity.test.ts:
65 |       { name: "nan", typeOid: OID[t] },
66 |       { name: "fin", typeOid: OID[t] },
67 |     ],
68 |     [Buffer.from("Infinity"), Buffer.from("-Infinity"), Buffer.from("NaN"), Buffer.from("1.5")],
69 |   );
70 |   expect(row.pos).toBe(Infinity);
                       ^
error: expect(received).toBe(expected)

Expected: Infinity
Received: NaN

      at <anonymous> (/workspace/bun/test/js/sql/postgres-float-infinity.test.ts:70:19)
(fail) scalar float8 text 'Infinity'/'-Infinity'/'NaN' decode correctly [453.87ms]
65 |       { name: "nan", typeOid: OID[t] },
66 |       { name: "fin", typeOid: OID[t] },
67 |     ],
68 |     [Buffer.from("Infinity"), Buffer.from("-Infinity"), Buffer.from("NaN"), Buffer.from("1.5")],
69 |   );
70 |   expect(row.pos).toBe(Infinity);
                       ^
error: expect(received).toBe(expected)

Expected: Infinity
Received: NaN

      at <anonymous> (/workspace/bun/test/js/sql/postgres-
... (truncated)

release without fix: 2 FAILED
bun test v1.4.0-canary.1 (1498d7b77)

test/js/sql/postgres-float-infinity.test.ts:
65 |       { name: "nan", typeOid: OID[t] },
66 |       { name: "fin", typeOid: OID[t] },
67 |     ],
68 |     [Buffer.from("Infinity"), Buffer.from("-Infinity"), Buffer.from("NaN"), Buffer.from("1.5")],
69 |   );
70 |   expect(row.pos).toBe(Infinity);
                       ^
error: expect(received).toBe(expected)

Expected: Infinity
Received: NaN

      at <anonymous> (/workspace/bun/test/js/sql/postgres-float-infinity.test.ts:70:19)
(fail) scalar float8 text 'Infinity'/'-Infinity'/'NaN' decode correctly [9.51ms]
65 |       { name: "nan", typeOid: OID[t] },
66 |       { name: "fin", typeOid: OID[t] },
67 |     ],
68 |     [Buffer.from("Infinity"), Buffer.from("-Infinity"), Buffer.from("NaN"), Buffer.from("1.5")],
69 |   );
70 |   expect(row.pos).toBe(Infinity);
                       ^
error: expect(received).toBe(expected)

Expected: Infinity
Received: NaN

      at <anonymous> (/workspace/bun/test/js/sql/postgres-float-infinity.test.ts:70:19)
(fail) scalar float4 text 'Infinity'/'-Infinity'/'NaN' decode correctly [2.12ms]
(pass) float8_array text '{Infinity,-Infinity,NaN,1.5}' dec
... (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/mechgate.xml" test/js/sql/postgres-float-infinity.test.ts
bun test v1.4.0 (410458502)

test/js/sql/postgres-float-infinity.test.ts:
(pass) scalar float8 text 'Infinity'/'-Infinity'/'NaN' decode correctly [444.72ms]
(pass) scalar float4 text 'Infinity'/'-Infinity'/'NaN' decode correctly [139.82ms]
(pass) float8_array text '{Infinity,-Infinity,NaN,1.5}' decodes to [Infinity, -Infinity, NaN, 1.5] [74.91ms]
(pass) float4_array text '{Infinity,-Infinity,NaN,1.5}' decodes to [Infinity, -Infinity, NaN, 1.5] [63.97ms]

 4 pass
 0 fail
 16 expect() calls
Ran 4 tests across 1 file. [3.23s]
__F:0:S:0

release with fix: all passed
$ bun scripts/build.ts --profile=release
[configured] bun-profile → bun (stripped) in 715ms (unchanged)
ninja: Entering directory `/workspace/bun/build/release'
[0/57] cargo bun_bin → libbun_rust.a (--target x86_64-unknown-linux-gnu)

  nightly-2026-07-20-x86_64-unknown-linux-gnu unchanged - rustc 1.99.0-nightly (9f36de775 2026-07-19)

^[[1m^[[92m   Compiling^[[0m bun_react_compiler v0.0.0 (/workspace/bun/src/react_compiler)
^[[1m^[[92m   Compiling^[[0m bun_exe_format v0.0.0 (/workspace/bun/src/exe_format)
^[[1m^[[92m   Compiling^[[0m bun_css v0.0.0 (/workspace/bun/src/css)
^[[1m^[[92m   Compiling^[[0m bun_js_parser v0.0.0 (/workspace/bun/src/js_parser)
^[[1m^[[92m   Compiling^[[0m bun_resolver v0.0.0 (/workspace/bun/src/resolver)
^[[1m^[[92m   Compiling^[[0m bun_ini v0.0.0 (/workspace/bun/src/ini)
^[[1m^[[92m   Compiling^[[0m bun_router v0.0.0 (/workspace/bun/src/router)
^[[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
... (truncated)

diff hotspot

src/sql_jsc/postgres/DataCell.rs            |  4 +-
 test/js/sql/postgres-float-infinity.test.ts | 87 +++++++++++++++++++++++++++++
 2 files changed, 89 insertions(+), 2 deletions(-)

gate history · 3 passed · 0 rejected · iteration 8

evidence per changed file

file                                         reads  edits  tests
src/sql_jsc/postgres/DataCell.rs                 3      2      0
test/js/sql/postgres-float-infinity.test.ts      1      2      0

[coderabbitai]

Walkthrough

Changes

Postgres float decoding

Layer / File(s)	Summary
Use parse_f64 for text floats src/sql_jsc/postgres/DataCell.rs	Float8 and float4 text decoding now uses bun_core::fmt::parse_f64, retaining the NaN fallback.
Validate scalar and array decoding test/js/sql/postgres-float-infinity.test.ts	Scripted Postgres responses verify special float tokens and numeric values for scalar and array text paths.

Suggested reviewers: jarred-sumner

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly and concisely describes the scalar PostgreSQL float decoding fix for Infinity and -Infinity.
Description check	✅ Passed	The description includes the required sections, explains the cause and fix, and documents verification results for the new tests.

---

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

[claude]

LGTM — two-line swap to a strictly-more-capable parser helper, with a hermetic test that pins the exact wire tokens.

Extended reasoning...

Overview

Two-line production change in src/sql_jsc/postgres/DataCell.rs: the scalar float8/float4 text-decode path swaps bun_core::parse_double for bun_core::fmt::parse_f64. A new test file drives a scripted simple-query backend to send the exact Infinity/-Infinity/NaN/1.5 text tokens Postgres' float8out emits, for both float8 and float4, plus a pin on the already-correct float8[] path.

Verified mechanism

I read both helpers in src/bun_core/fmt.rs. parse_double is a partial-match wrapper over WTF__parseDouble with no special-casing; parse_f64 is the full-match variant that additionally recognises sign-prefixed case-insensitive inf/infinity/nan (fmt.rs:1006-1020). Postgres float8out never emits trailing garbage, so the partial→full-match tightening is safe, and the .unwrap_or(f64::NAN) fallback is preserved. bun_core::fmt::parse_f64 is already the established call at four other sites in the tree.

Security risks

None. No untrusted-size arithmetic, allocation, or FFI surface changes — the input bytes flow through the same code path as before, just into a different pure-parse helper.

Level of scrutiny

Low. This is a focused decoder bugfix with a clear root cause (JS-number grammar rejects Infinity), a two-call-site change, and an in-tree helper that already implements exactly the needed behaviour. The test is hermetic (local net.Server on an ephemeral port, no live Postgres), covers both float widths plus a finite control value, and pins the sibling array path.

Other factors

The one inline nit (unused float4_array OID constant / missing float4[] array case) is cosmetic and doesn't block — the production change applies identically to both float widths and float4[] routes through the same parse_array Infinity arm the float8[] test already pins.

[claude]

LGTM — two-line swap to bun_core::fmt::parse_f64 for the scalar float8/float4 text path, with the earlier nit (float4[] array coverage) and comment-cop flag both addressed.

What was reviewed:

• Confirmed parse_f64 wraps the same WTF__parseDouble call and only adds case-insensitive inf/infinity/nan arms; the stricter full-input-consumed check can't regress Postgres float8out output, which never emits trailing bytes.
• Test follows the established wire-frames.ts scripted-backend pattern used by ~25 other files in test/js/sql/; serial tests so the shared reply slot is safe.
• Verified the follow-up commits: array test now covers both float8_array and float4_array, and the flagged inline comment was dropped.

Extended reasoning...

Overview

The PR changes two call sites in src/sql_jsc/postgres/DataCell.rs — the text-format decode arms for T::float8 and T::float4 — from bun_core::parse_double(bytes) to bun_core::fmt::parse_f64(bytes). It adds test/js/sql/postgres-float-infinity.test.ts, which drives a scripted simple-query backend to send text-format Infinity / -Infinity / NaN / 1.5 in float8, float4, float8[], and float4[] columns.

I read bun_core::fmt::parse_f64 (fmt.rs:995-1025) and bun_core::parse_double (fmt.rs:967-978). Both call WTF__parseDouble. parse_f64 differs in two ways: (1) when count == 0 it falls back to case-insensitive inf/infinity/nan matching with optional +/- — exactly the tokens Postgres float8out emits; (2) for numeric input it requires the whole slice to be consumed (count == s.len()) rather than accepting a prefix. Postgres never emits trailing garbage after a float text value, so (2) cannot regress real wire data and is arguably more correct. The .unwrap_or(f64::NAN) fallback is preserved.

Security risks

None. This is a read-side text-to-double conversion of server-sent bytes; no allocation, no unsafe, no user-controlled sizing. The change narrows accepted input (rejects trailing garbage) rather than widening it.

Level of scrutiny

Low. A two-line helper swap in a well-understood decode path, backed by a test that demonstrably fails on main and passes with the fix (evidence block shows both ASAN-debug and release runs). The array path already handled these tokens the same way, so this brings the scalar path into agreement rather than introducing new behaviour.

Other factors

• My prior review left one nit (unused float4_array OID / missing float4[] array coverage); commit 7bd1ddb addressed it by turning the array test into test.each over both widths, and the thread is resolved.
• The comment-cop bot flagged an inline comment; commit 2111c02 dropped it, and that thread is also resolved.
• The test reuses the established wire-frames.ts helpers (listeningServer, pgRowDescription, pgDataRow, etc.) and the same shared-server + per-test new SQL shape used across the test/js/sql/ directory. Tests are serial so the module-level reply slot is race-free; each connection is closed in finally and the server in afterAll.

[claude]

LGTM — the earlier nit (unused float4_array OID → now covered by test.each) and the comment-cop flag are both addressed.

What was reviewed:

• Confirmed bun_core::fmt::parse_f64 wraps WTF::parseDouble and adds case-insensitive inf/infinity/nan arms with sign handling, matching what Postgres float8out emits.
• Checked the semantic delta vs parse_double (full-match vs prefix-match) — Postgres never emits trailing bytes in float text output, and the unwrap_or(f64::NAN) fallback is unchanged, so no regression for finite values.
• Test follows the established wire-frames.ts scripted-backend pattern from sibling postgres-infinity-date.test.ts; sequential tests share the module-level reply safely since none are test.concurrent.

Extended reasoning...

Overview

Two-line source change in src/sql_jsc/postgres/DataCell.rs swapping bun_core::parse_double for bun_core::fmt::parse_f64 in the T::float8 and T::float4 text-format arms of from_bytes. New test file test/js/sql/postgres-float-infinity.test.ts (87 lines) drives a scripted simple-query backend to pin scalar float8/float4 and array float8[]/float4[] decoding of Infinity/-Infinity/NaN/1.5.

Security risks

None. This is output-side parsing of bytes the Postgres server sent; the change replaces one in-tree float parser with a strict superset that additionally recognises the IEEE special-value tokens. No new allocation, no untrusted-length arithmetic, no user-controlled control flow.

Level of scrutiny

Low. The source change is a helper swap where I verified the target helper's implementation (fmt.rs:995-1025): it calls the same WTF__parseDouble and, only when zero characters were consumed, falls through to case-insensitive matching of inf/infinity/nan with optional +/-. The one behavioural difference — parse_f64 requires the full input to be consumed whereas parse_double accepted any nonzero prefix — is irrelevant here because Postgres float8out/float4out never emit trailing bytes, and the .unwrap_or(f64::NAN) fallback is retained so degenerate input can't get worse than before.

Other factors

• The PR description includes fails-on-main / passes-on-PR evidence for both debug-ASAN and release builds.
• My previous nit (unused float4_array OID entry / missing float4[] variant coverage) was addressed in 7bd1ddb by turning the array test into test.each(["float8_array", "float4_array"]); the comment-cop inline-comment flag was addressed in 2111c02. Both threads are resolved.
• The test reuses the shared wire-frames.ts helpers (listeningServer, pgRowDescription, pgDataRow, etc.) exactly as ~20 sibling tests do, and mirrors the structure of postgres-infinity-date.test.ts for the analogous date-infinity fix.
• No CODEOWNERS entry covers src/sql_jsc/postgres/.

[robobun]

The diff itself is green: the new test/js/sql/postgres-float-infinity.test.ts passes on every lane, and the only source change is a two-line helper swap in src/sql_jsc/postgres/DataCell.rs.

CI builds 84189 and 84221 each show a rotating set of pre-existing flaky tests (spawn-streaming-stdout, napi, fetch-tls, streams-leak, node-sqlite GC, etc.), all tagged [flaky] by ci:errors, none in test/js/sql/ or anywhere this change could reach. Ready for review/merge.

[robobun]

^{Updated 11:05 AM PT - Jul 29th, 2026}

❌ @Jarred-Sumner, your commit 4104585 has 2 failures in Build #85265 (All Failures):

• test/js/web/websocket/websocket-subprotocol-strict.test.ts - crash reported on 🍎 26 aarch64
• test/js/bun/util/filesystem_router.test.ts - pid 3783 segmentation fault on 🐧 25.04 aarch64

---

🧪   To try this PR locally:

bunx bun-pr 36239

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

bun-36239 --bun

[claude]

LGTM — two-line helper swap, and the earlier nit (float4[] array coverage) is addressed.

What was reviewed:

• Confirmed bun_core::fmt::parse_f64 wraps the same WTF__parseDouble and only adds the inf/infinity/nan arms; ordinary numeric text is unchanged.
• parse_f64 is full-match vs parse_double's prefix-match, but Postgres float8out/float4out never emit trailing bytes and the .unwrap_or(NaN) fallback is retained.
• Test uses the shared wire-frames.ts scripted backend on an ephemeral port; tests run serially so the shared reply state is safe.

Extended reasoning...

Overview

The PR swaps bun_core::parse_double for bun_core::fmt::parse_f64 in the two scalar text-decode arms (T::float8 and T::float4) of src/sql_jsc/postgres/DataCell.rs. parse_f64 calls the same WTF__parseDouble FFI and, when zero bytes are consumed, additionally matches sign-prefixed case-insensitive inf/infinity/nan — exactly the tokens Postgres's float8out emits. The array text path (parse_array) already handled these tokens via explicit starts_with_case_insensitive_ascii checks, so this brings the scalar path into agreement. A new test file drives a scripted simple-query backend from the existing test/js/sql/wire-frames.ts helper to pin both scalar (float8, float4) and array (float8[], float4[]) decoding of Infinity/-Infinity/NaN/1.5.

Security risks

None. This is a pure decode-side change to how a text token from a Postgres server is turned into a JS number. No new allocations, no untrusted-length arithmetic, no user-controllable code paths beyond what already existed. The .unwrap_or(f64::NAN) fallback is preserved, so malformed input still degrades to NaN rather than erroring or panicking.

Level of scrutiny

Low. Two identical one-line changes replacing one in-tree helper with another whose implementation I read (src/bun_core/fmt.rs:995-1020). The only semantic difference beyond the inf/nan arms is that parse_f64 requires a full match while parse_double accepted a numeric prefix — irrelevant here because Postgres's float text output is always a clean token, and the NaN fallback covers anything unexpected. The PR includes fails-on-main / passes-on-PR evidence.

Other factors

My earlier nit (unused float4_array OID entry / missing float4[] variant coverage) was addressed in 7bd1ddb by turning the array test into a test.each over both array widths. The comment-cop flag was resolved in 2111c02. All review threads are marked resolved. The test reuses the established wire-frames.ts scripted-backend pattern (ephemeral-port TCP server, no external network), closes the SQL client in finally and the server in afterAll, and the shared module-level reply state is safe because the tests are not test.concurrent. CI failures noted in the thread are pre-existing flakes unrelated to test/js/sql/.

[claude]

LGTM — two-line helper swap with a scripted-backend regression test; the earlier nit (float4_array coverage) is addressed.

What was reviewed:

• Confirmed bun_core::fmt::parse_f64 wraps the same WTF__parseDouble as parse_double and only adds case-insensitive inf/infinity/nan arms plus a full-match requirement — no behaviour change for the canonical decimal strings Postgres emits.
• Checked the remaining parse_double call in the array numeric arm: it's only reached after the tokenizer has already consumed Infinity/NaN, so no sibling fix needed.
• Test imports all resolve against the existing test/js/sql/wire-frames.ts harness; the shared reply mutable is safe under sequential test.each.

Extended reasoning...

Overview

The source change is exactly two identical lines in src/sql_jsc/postgres/DataCell.rs: the T::float8 and T::float4 text-format arms swap bun_core::parse_double(bytes).unwrap_or(f64::NAN) for bun_core::fmt::parse_f64(bytes).unwrap_or(f64::NAN). I read both helpers in src/bun_core/fmt.rs: they call the same WTF__parseDouble FFI, but parse_f64 (a) requires the whole input to be consumed rather than accepting a prefix, and (b) falls back to case-insensitive inf/infinity/nan with optional sign when WTF consumed zero bytes. Postgres float8out only ever emits a canonical decimal or one of those three tokens, so (a) is a no-op on real wire data and (b) is exactly the bug fix.

The new test file drives a scripted simple-query backend via the existing test/js/sql/wire-frames.ts helpers, sending text-format Infinity/-Infinity/NaN/1.5 for float8, float4, float8[], and float4[]. The evidence block shows it fails on the debug build without the fix and passes with it.

Security risks

None. Safe Rust, identical &[u8] -> Option<f64> shape, no allocation, no user-controlled indexing. The stricter full-match semantics of parse_f64 are, if anything, more defensive against malformed wire bytes than the previous prefix-accepting parse_double.

Level of scrutiny

Low. This is a mechanical helper substitution in a text-decode path with a demonstrated fails-before/passes-after test. The array path in the same file already handled these tokens via its own tokenizer, so the fix brings the scalar path into agreement rather than introducing new behaviour. I checked the one remaining parse_double call in parse_array's numeric arm — it's only reachable for strings starting with [-0-9] after I/i/N have been peeled off, so it never sees infinity/nan and doesn't need changing.

Other factors

My earlier nit about the unused float4_array OID entry was addressed in 7bd1ddb by turning the array test into a test.each over both widths, and the comment-cop flag on the source file was resolved in 2111c02. All inline threads are resolved. The test uses a module-level reply mutable shared across a single listeningServer, which is safe because test.each runs sequentially and each runSimple opens a fresh max: 1 connection; the pattern matches pgMinimalReadyServer in the shared harness. CI on the touched test file is green per the robobun summary.