http: fix http client leaky with double response

[theanarkh]

Fixed: #60025

When a request corresponds to multiple responses, ensure that only the first one is processed and skip all subsequent invalid responses (or emit a response event then emit an error event on request object ?).

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[nodejs-github-bot]

Review requested:

• @nodejs/http
• @nodejs/net

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.56%. Comparing base (db0121b) to head (88c0254).
⚠️ Report is 28 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #60062 +/- ##
==========================================
+ Coverage 88.53% 88.56% +0.02% 
==========================================
Files 704 704 Lines 208087 208097 +10 Branches 40010 40009 -1 ==========================================
+ Hits 184239 184297 +58 + Misses 15866 15816 -50 - Partials 7982 7984 +2 

Files with missing lines	Coverage Δ
lib/_http_client.js	97.35% <100.00%> (+0.02%)	⬆️
lib/_http_common.js	100.00% <100.00%> (ø)

... and 39 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pimterry]

One minor point, otherwise LGTM.

---

or emit a response event then emit an error event on request object ?

Emitting an error here would be a breaking change that will probably break things for some people in real cases. Without that, I don't think this is semver-major, since other than the leak the 2nd response doesn't seem to have been observable until now.

I think emitting an error would probably still be best, because it is an error case where something's clearly gone wrong, and this matches our docs, which say

If any error is encountered during the request (be that with DNS resolution, TCP level errors, or actual HTTP parse errors) an 'error' event is emitted on the returned request object

but that said, it might be better to separate the two issues.

How about we aim to ship this to resolve the leak, and then ship a separate semver-major PR making this into an emitted request error in future?

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/69646/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/69653/

[mcollina]

lgtm

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/69691/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/69698/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/69708/

[nodejs-github-bot]

Landed in 59b70e5