fix: guard processSendQueue against non-writable stream status

[lodekeeper]

What

Add a writeStatus guard at the top of processSendQueue() in abstract-message-stream.ts to bail out when the stream is no longer writable.

Why

A race condition causes an uncaught StreamStateError when a drain event fires on a stream whose underlying transport is already closing:

1. TCP connection starts closing → writeStatus transitions to 'closing'
2. A drain event fires on the underlying TCP stream
3. The noise layer relays this as safeDispatchEvent('drain') on the encrypted stream
4. continueSendingOnDrain → processSendQueue() → sendData() → send() on the now-closing stream
5. send() throws StreamStateError — inside an event listener with no try/catch → uncaught exception

Observed on Lodestar mainnet (v1.41.0, @libp2p/utils@7.0.13): 6 uncaught exceptions in 7 days.

Fix

Single guard at the top of processSendQueue(), consistent with the existing bail-out pattern:

if (this.writeStatus !== 'writable') {
  this.log.trace('not processing send queue as stream write status is %s', this.writeStatus)
  return false
}

Test

Added a regression test that:

1. Creates a stream pair with capacity: 1 to trigger backpressure
2. Fills the send buffer until send() returns false
3. Sets writeStatus to 'closing'
4. Dispatches a drain event
5. Asserts sendData is NOT called (the guard catches it) and no error is thrown

Closes #3415

[dozyio]

@lodekeeper - can you review this commit 17d9da8 please

[lodekeeper]

@dozyio Reviewed commit 17d9da8 — looks good overall.

abstract-message-stream.ts: The willSend defensive copy + comment makes the intent clear — guard against sendData mutating the slice before throwing. The rename is cleaner than the original toSend requeue. No issues here.

Tests: Both cases are solid:

• preserve on error: verifies buffer is intact after a StreamStateError on drain ✓
• no duplication on transient error: the throwOnce pattern correctly proves data isn't counted twice across two drain events ✓

One minor note: the second test sets writeStatus = 'closing' before the first drain but the continueSendingOnDrain guard only bails on statuses that are neither 'writable' nor 'closing'. So 'closing' still reaches the try/catch — which is the right flow for the test to exercise. Just worth a comment in the test body if you want it to be self-documenting, but it's not required.

Happy to address any remaining feedback before merge.

[dozyio]

@lodekeeper it seems test are failing after merging latest main branch - could you investigate?

[lodekeeper]

@dozyio Investigated — pushed cbc1f2e2d.

Root cause: the merge of main brought in #3435 (commit 5917715d0c), which wraps processSendQueue() in queueMicrotask(...) inside the drain handler to prevent a Maximum call stack size exceeded error. After that change, the two drain-race tests added in 17d9da8ab (should preserve queued bytes when sendData throws StreamStateError during drain and should not duplicate queued bytes after transient StreamStateError during drain) dispatch a synchronous drain event and then immediately assert on stub.calledOnce / writeBufferLength, but sendData is now deferred to a microtask — so the stub has been called 0 times when the assertion fires (expected false to be true at line 495).

Fix: await a microtask flush (await new Promise<void>((resolve) => { queueMicrotask(resolve) })) between dispatchEvent('drain') and the post-drain assertions. Preserves test intent (sendData is still invoked, bytes are still preserved / requeued); just adapts to the deferred scheduling. No source change needed.