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 15 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/