Split out of #391, which landed a fix without the regression test this repo's guidance requires.
The untested fix
ez::Driver::accept_bi skips both self.send and Priorities when the accepted send half is already closed — the peer sent STOP_SENDING before we accepted, so the first SendState::flush came back terminal and nothing will ever flush it again. Without the guard the entry leaks for the life of the connection and holds an urgency band, letting a peer flatten live streams' relative ordering.
Reverting both if live guards passes every test in the crate today.
Why it wasn't written
Reproducing the condition needs the peer's STOP_SENDING to be processed before the driver accepts the stream, which depends on quiche's ordering within a single packet batch. From an integration test that race isn't deterministic, and a test that only sometimes reproduces it is worse than none — it passes whether or not the fix is present.
Every test in rs/web-transport-quiche/tests/ goes over a real socket, so there is no seam for driving Driver directly.
What would fix it
An in-memory QuicheConnection pair for unit tests — quiche::Connection<BufFactory> is a plain type alias (tokio_quiche::quic::QuicheConnection), so a client/server pair can be handshaked by pumping send/recv buffers between them with no sockets, the way quiche's own tests do. The awkward part is quiche::Config wanting cert paths rather than in-memory DER.
With that harness the test is direct: hand the server connection a bidi stream plus STOP_SENDING, call accept_bi, and assert the stream is absent from Driver::send and unranked in Priorities.
The harness would also unblock the lifecycle tests that #391 could not write — see the "Deliberately not included" section there for the two priority-ranking defects still open, both of which need driver-level tests to fix safely.
(written by claude-opus-5)
Split out of #391, which landed a fix without the regression test this repo's guidance requires.
The untested fix
ez::Driver::accept_biskips bothself.sendandPrioritieswhen the accepted send half is already closed — the peer sentSTOP_SENDINGbefore we accepted, so the firstSendState::flushcame back terminal and nothing will ever flush it again. Without the guard the entry leaks for the life of the connection and holds an urgency band, letting a peer flatten live streams' relative ordering.Reverting both
if liveguards passes every test in the crate today.Why it wasn't written
Reproducing the condition needs the peer's
STOP_SENDINGto be processed before the driver accepts the stream, which depends on quiche's ordering within a single packet batch. From an integration test that race isn't deterministic, and a test that only sometimes reproduces it is worse than none — it passes whether or not the fix is present.Every test in
rs/web-transport-quiche/tests/goes over a real socket, so there is no seam for drivingDriverdirectly.What would fix it
An in-memory
QuicheConnectionpair for unit tests —quiche::Connection<BufFactory>is a plain type alias (tokio_quiche::quic::QuicheConnection), so a client/server pair can be handshaked by pumpingsend/recvbuffers between them with no sockets, the way quiche's own tests do. The awkward part isquiche::Configwanting cert paths rather than in-memory DER.With that harness the test is direct: hand the server connection a bidi stream plus
STOP_SENDING, callaccept_bi, and assert the stream is absent fromDriver::sendand unranked inPriorities.The harness would also unblock the lifecycle tests that #391 could not write — see the "Deliberately not included" section there for the two priority-ranking defects still open, both of which need driver-level tests to fix safely.
(written by claude-opus-5)