fix: settle connection.closed() when the connection is aborted

[nflaig]

Connection::closed() resolves only once quinn reports the connection closed, so if the connection driver stalls it never resolves - the same condition #64 works around at the endpoint level. The JS side keeps one of these pending per connection for its whole lifetime (src/connection.ts), and it is the only thing that tells the transport the connection died:

this.#connection.closed().then(() => { this.onTransportClosed() }, (err) => { this.onTransportClosed(err) })

So a stalled driver does not just leak the napi deferred behind that promise, it leaves libp2p believing a dead connection is still live.

Settle closed() on abort() as well as on the connection actually closing. watch + send_replace rather than Notify or plain send, both of which drop the signal when nothing has subscribed yet, and subscribe() + borrow_and_update() so an abort() that lands before the first closed() is still seen.

No API change, closed() is still Promise<void> and abort() still void.

Worth a close look on review: onTransportClosed() now fires when abort() is called rather than when quinn confirms the close. That is a small timing change in the connection lifecycle and I am not the right person to judge whether anything downstream depends on the old ordering.

This does not fix the Lodestar shutdown hang I originally wrote it for

I believed the pending closed() deferreds left the worker thread blocked in native code. gdb stacks from a live wedged Lodestar worker show otherwise - the thread is spinning in Node's own Environment::CleanupHandles(), which loops uv_run(UV_RUN_ONCE) until handle_wrap_queue_ drains:

Thread 73 (LWP 1524870 "WorkerThread"):     <- state R, on CPU
#2  uv_run (loop=0x7fd473dc6938, mode=UV_RUN_ONCE)
#3  node::Environment::CleanupHandles()
#4  node::Environment::RunCleanup()
#5  node::worker::Worker::Run()

A later capture walked that loop and found 6 handles left, only 2 of them plain UV_ASYNC, fewer than a healthy loop has. Not a pile of leaked napi threadsafe functions.

Measured on a mainnet node, soaking at ~200 peers with 90-160 live inbound QUIC connections for at least 5 minutes before each shutdown:

	shutdowns	worker failed to terminate
2.1.2	5	1
this patch	20	4

Identical rate, so the hypothesis was wrong. No regression observed over those 20 shutdowns either.

Review this as a correctness fix - a promise that can never settle, and a transport that never learns its connection died - not as a fix for anything. Lodestar side mitigation, which keeps a stuck worker from costing the node its state archive, is ChainSafe/lodestar#9790. Root cause notes and captures: https://gist.github.com/nflaig/b266d89c03cdd2c76338823afed5b2c0

AI Assistance Disclosure

Written and measured with Claude Code, validated on a mainnet node as above.

🤖 Generated with Claude Code

[spiral-ladder]

lgtm wiht optional comment