net: ignore UV_EALREADY in tryReadStart

[harjothkhara]

tryReadStart() treated every non-zero readStart() result as fatal. That
included UV_EALREADY, which means the handle is already reading and no
additional action is required.

Ignore UV_EALREADY while preserving the existing socket destruction path for
all other read-start errors. Add a loopback regression test that forces this
return value and verifies that the socket remains usable.

Fixes: #62400

Tests:

• make -j8
• tools/test.py test/parallel/test-net-read-start-ealready.js
• tools/test.py test/parallel/test-net-*.js
• make lint-js

AI assistance: OpenAI Codex assisted with implementation and validation. Local
Claude and Codex review passes reported no actionable findings.

[nodejs-github-bot]

Review requested:

• @nodejs/net

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.24%. Comparing base (608112a) to head (09c630a).
⚠️ Report is 6 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #64530      +/-   ##
==========================================
+ Coverage   90.21%   90.24%   +0.02%     
==========================================
  Files         739      739              
  Lines      241650   241699      +49     
  Branches    45542    45544       +2     
==========================================
+ Hits       218013   218118     +105     
+ Misses      15155    15109      -46     
+ Partials     8482     8472      -10     

Files with missing lines	Coverage Δ
lib/net.js	94.37% <100.00%> (+<0.01%)	⬆️

... and 35 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]

The repro in that issue requires manually patching socket handle internals. Is this actually reachable in practice? In theory I think we already check for !this._handle.reading before calling tryReadStart so I'm not sure the issue is actually possible in normal Node code (and so might just be related to the AF_CAN implementation mentioned there).

Notably there are zero reports of Node issues that mention UV_EALREADY other than this one, which reinforces that. Right now, AFAICT the only way this can happen is if our JS reading state gets out of sync from libuv. We can guard against that, but it's debatable - it might be better to fail loudly so we do spot real issues there.

[harjothkhara]

You're right. I checked how UV_EALREADY can actually come back from readStart(): libuv only returns it when the handle is already reading (uv_read_start in deps/uv/src/uv-common.c). Since tryReadStart is only called when _handle.reading is false, the error needs the JS flag to say "not reading" while libuv is still reading.

I looked at every place in core that touches the flag, and that mismatch doesn't seem possible with current socket types. Everywhere that sets _handle.reading = false also calls readStop(), and everywhere C++ starts reading also sets the flag to true (the HTTP server and agent). The repro in #62400 only gets there by replacing the handle's methods by hand.

So I agree this doesn't look reachable in normal Node code today. It would only show up with a handle type that starts reading on its own, like the AF_CAN work in #62398. Given that, it probably makes more sense to close this and revisit if #62398 lands. Also fine keeping it open until then if you think the guard is worth having. Whatever you prefer.

[pimterry]

Given that, it probably makes more sense to close this and revisit if #62398 lands.

Yeah, I'm leaning that way. I'll close this. The code does look correct and it's not totally unreasonable, but for now I don't think we should silently handle this, given that currently it implies a serious internal error somewhere.

If we do reach a point in future where there's a good reason why this might happen I'd be happy to reconsider.