Review requested:

• @nodejs/quic

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

@nodejs/quic @mcollina ... there is an API design question in this... right now, the module maintains a global set of QuicEndpoint instances for re-use. When calling connect(), it will, by default, use an existing QuicEndpoint if one is available. The selection is pretty unsophisticated (use the first active one in the list). Should we introduce a pluggable QuicAgent mechanism that allows users to customize the selection process? The default QuicAgent would use the current behavior, but the user could potentially have something like const agent = new MyQuicAgent(); const session = connect(..., { agent }) to provide their own re-use strategy. I went with the simple global agent for now.

The module-level listEndpoints API makes sense for that, but if we end up wanting a QuicAgent type of mechanism then we should do that now.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.37%. Comparing base (df09b2a) to head (b6bde18).
⚠️ Report is 82 commits behind head on main.

@@            Coverage Diff             @@
##             main   #63536      +/-   ##
==========================================
+ Coverage   90.32%   90.37%   +0.05%     
==========================================
  Files         730      730              
  Lines      234152   234521     +369     
  Branches    43900    44141     +241     
==========================================
+ Hits       211499   211954     +455     
+ Misses      14374    14328      -46     
+ Partials     8279     8239      -40     

... and 39 files with indirect coverage changes

• ❄️ 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.

Please look at the discussion at:
https://www.w3.org/wiki/WebTransport/Meetings2023#WebTransport_Bi-weekly_Virtual_Meeting_#125_-_May_19_2026 (see part beginning with "Pooled stats counters persist across session boundaries #762" )
There are some privacy concerns on sharing webtransport sessions. Probably not relevant for node.js more for the UA.
But certainly related to this new api. But there are other related discussions.

Overall yes, we should add an Agent system to make the reuse constrained and limited if someone needs that.

If we're going to add an agent, then I think this PR needs to take a different approach. Moving to draft for now.

Actually.. thinking about it more... a QuicAgent type of thing doesn't actually make sense :-) ... the QuicEndpoint already acts like an agent... user code can figure out whatever approach it wants to re-using them.

Specifically:

When connect(...) is called, it will create a QuicEndpoint automatically if one does not exist. Or, you can call new QuicEndpoint(...) to create one and pass it in with the connect(...) to use it. Or, you can use the endpoint directly to connect. The point being, it ends up largely serving the same role as the Agent in http 1 and 2.

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

+1 on the Agent mechanism

Landed in 0fe48b6