Repository navigation
quic: Should QuicStream be destroyed, if onstream is not set #64192
Description
Activity
Agreed - if we're exposing the stream via other APIs, it shouldn't mysteriously die if it's being used elsewhere. The invariant should be broader: if we get a stream, and it's not exposed at all (nothing listening to any relevant callback) then it should be cleaned up automatically so it's not left hanging. It's not really about the
onstreamcallback specifically.Opened #65335 implementing the invariant discussed here — an incoming stream is destroyed only when the session has no consumer at all for it: no
onstream, and no session-level stream callbacks runnable on the negotiated application (checked via the existingheadersSupportedstate). Stubonstreamhandlers are no longer needed to keep h3/WebTransport streams alive.Please take a look when you get a chance.
One related observation as a possible follow-up: per RFC 9114 §4.1.1, rejecting a request stream without processing it should signal
H3_REQUEST_REJECTEDso the client knows it is safe to retry. The destroy path currently sends the generic error code instead. If that sounds right, happy to pick it up as a small follow-up.- added 4 commits that reference this issue
on Aug 16, 2026 - added a commit that references this issue
on Aug 20, 2026 - added 2 commits that reference this issue
on Sep 7, 2026
Currently, incoming streams are destroyed, if the
onstreamcallback is not set.This sounds at first sight logically, however one can also use for http/3
onHeaderscallback, later with webtransport support, it would be alsoonsessionidwhich is called for a webtransport data stream.Then for http/3
onstreamis most times pretty useless, as the other callbacks, which are opposed to the current docu are called later thanonstreamfor h3 are more useful. So I have actually only stubs inonstream.This is related to @pimterry api redesign (@jasnell may be also interested).