http: ERR_STREAM_PREMATURE_CLOSE ("Premature close") regression on keep-alive requests, bisects to v24.17.0 — breaks gaxios/node-fetch (Google API clients)

[tobalsgithub]

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:

1. googleapis@144 Drive files.list (background polling loop, long-lived process)
2. @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?...: 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 http.Agent" (plus the TLS/SNI changes) — anything altering keep-alive socket reuse timing is a candidate.
• Independent same-day report (different OS, different Google tool): Firebase login issue firebase/firebase-tools#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 ("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 / google-auth-library stack still depends transitively on gaxios@6 → node-fetch@2, so the affected surface is broad.

[tomkosm]

+1 we had this happen on 22.23

[RaminKav]

had this happen to us too, thanks for making the issue

[derekmeegan]

+1 affected us as well. I believe this also affects v22.23.0

[dorsha]

Affected as well, really critical to fix, in all latest node versions.

[ami-descope]

+1 22.22.3

[newman-dani]

v22.23.0 is also broken!

[mmgroner]

Happened to us as well! We pinned our release versions to 24.13.0 to fix

Thanks for posting

[edkimmel]

I see the tag above, but https://github.com/edkimmel/node-24-fetch-repro is a standalone reproduction of the issue.

For our case, it needed all of the following.

• tls connection
• gzip response
• chunked response
• large enough response body to actually be chunked
• node-fetch 2.x

[crossan007]

I observed this as well when upgrading from the Docker container node:22.22.3 to node:22.23.0

nodejs/docker-node@10365a8

[ogulcantumdogan]

Same issue here, can confirm that a downgrade to 24.16 fixed the issue