fix(quic): stop ~ClientQUIC aborting the process on teardown #8
2026-08-25
fix(quic): bound the client handshake
QUIC_SETTINGS never set HandshakeIdleTimeoutMs, so it inherited the 120s idle timeout. The constructor blocks until msquic reports the connection either up or shut down, which meant dialling a host that does not answer parked the caller for minutes. Bound it to 10s. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
fix(quic): stop ~ClientQUIC racing the callback to close the connection
MsQuicConnectionClose was reachable twice for one handle: ~ClientQUIC called it unconditionally, and the SHUTDOWN_COMPLETE callback also called it whenever AppCloseInProgress was clear -- which it is for the whole window between the destructor's ConnectionShutdown and its ConnectionClose. The second call trips CXPLAT_TEL_ASSERT(!Connection->State.HandleClosed) and aborts the process. Clearing impl->connection from the callback did not help: the destructor had already loaded it. `connection` is now a claim token, taken under the mutex, and only whoever wins the claim closes. The callback keeps closing peer-dropped connections so they do not leak while their ClientQUIC lives on. Separately, the destructor now waits (bounded, 5s) for the connection's streams to reach StreamClose before closing it. QUICStream::Stop only initiates a shutdown whose async completion does the close, so a connection could otherwise be closed with streams msquic still considers open. The count lives in a shared StreamRegistry rather than behind the ClientQUIC*, so a stream finalising after the wait gave up decrements a live object. A failed handshake also closes its connection and configuration now. Throwing from the constructor body means ~ClientQUIC never runs, so both handles leaked -- and the connection callback holds the impl that was about to be destroyed with the half-built object. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
test(quic): cover connection teardown
Every other QUIC test ends in std::_Exit(0), so nothing in the suite ever ran a ~ClientQUIC. This adds 25 build-up/tear-down cycles with reader threads parked inside RecieveSync -- the shape a reconnect loop has -- which aborts on ~10/20 runs against the current implementation. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>