Node-Fetch on latest Node Update broken

Node.js v24.17.0 introduced a regression in the http subsystem that causes keep-alive requests to fail with ERR_STREAM_PREMATURE_CLOSE, breaking gaxios and node-fetch used by Google API clients. The issue was bisected to the v24.17.0 release and affects platforms including Linux and Windows, with no workaround other than pinning to v24.16.0.

- - Notifications /login?return to=%2Fnodejs%2Fnode You must be signed in to change notification settings - Fork 35.7k /login?return to=%2Fnodejs%2Fnode http: ERR STREAM PREMATURE CLOSE "Premature close" regression on keep-alive requests, bisects to v24.17.0 — breaks gaxios/node-fetch Google API clients 63989 Description Version v24.17.0 Platform Reproduced on Linux x64 Cloud Run / gVisor, Debian 12 . A second, independent report is on Windows 11 x64 see firebase-tools 10681 below , so this appears to be platform-independent and runtime-version-driven. Subsystem http / http.Agent keep-alive socket reuse What steps will reproduce the bug? I don't yet have a reduced standalone repro, but the behavior change is sharply bisected and reproduces across two independent code paths plus a second reporter: Both paths run through gaxios@6.7.1 → node-fetch@2.7.0 → core node:http with a keep-alive http.Agent , making requests to .googleapis.com : googleapis@144 Drive files.list background polling loop, long-lived process @google-cloud/storage@7.14.0 v4 signed-URL signing via google-auth-library@9.15.0 GoogleAuth.signBlob → https://iamcredentials.googleapis.com/.../:signBlob Both began failing immediately on a deploy whose only material change was the Node runtime moving from 24.16.0 → 24.17.0 a floating node:24-slim base image picked up the same-day 24.17.0 release . No dependency versions changed. Pinning the image back to node:24.16.0-slim fully resolves both. A likely minimal-repro shape from the related node-fetch issue below is a keep-alive https.Agent { keepAlive: true, maxSockets: N } issuing more than N sequential/concurrent requests to a chunked or gzip-encoded HTTPS endpoint. I'm happy to invest in a self-contained reproduction if that would help — wanted to file the bisect promptly given the blast radius. How often does it reproduce? Is there a required condition? Reliably under load on 24.17.0; never on 24.16.0. Appears tied to keep-alive socket reuse — the failure is a premature close on a reused pooled socket. What is the expected behavior? Why is that the expected behavior? Keep-alive pooled HTTP requests that complete normally on 24.16.0 should continue to complete on 24.17.0 without the response body being reported as prematurely closed. What do you see instead? FetchError: Invalid response body while trying to fetch https://www.googleapis.com/drive/v3/files https://www.googleapis.com/drive/v3/files ?...: Premature close code: ERR STREAM PREMATURE CLOSE and on the signing path: SigningError: Invalid response body while trying to fetch https://iamcredentials.googleapis.com/.../:signBlob: Premature close gaxios@6.7.1/gaxios.ts:157 google-auth-library@9.15.0 GoogleAuth.signBlob Additional information Suspected cause: the 24.17.0 changelog entry "http: fix response queue poisoning in plus the TLS/SNI changes — anything altering keep-alive socket reuse timing is a candidate. http.Agent " Independent same-day report different OS, different Google tool : Firebase login issue firebase/firebase-tools 10681 https://github.com/firebase/firebase-tools/issues/10681 — FetchError ... Premature close on https://accounts.google.com/o/oauth2/token , Node v24.17.0, Windows 11. Latent library-side bug being exposed: Malformed chunked response detector creates false-positive ‘premature close’ errors when HTTP Agent involved node-fetch/node-fetch 1767 https://github.com/node-fetch/node-fetch/issues/1767 "Malformed chunked response detector creates false-positive 'premature close' errors when HTTP Agent involved" . It's plausible 24.17.0 is correctly surfacing a long-standing node-fetch defect rather than itself being wrong — but since the observable trigger is the runtime bump and node-fetch@2 is effectively unmaintained, confirmation of whether this is intended/expected behavior at the http.Agent level vs. a fix-forward in 24.17.x would help a large slice of the Google-API-client ecosystem decide how to respond.- The whole googleapis / @Google-Cloud https://github.com/Google-Cloud / google-auth-library stack still depends transitively on gaxios@6 → node-fetch@2 , so the affected surface is broad. Metadata Metadata Assignees Labels Type Fields Give feedback https://github.com/orgs/community/discussions/189141