mirror of
https://github.com/nodejs/node.git
synced 2026-11-09 15:11:11 -05:00
trivenay
fd5b13557f
An incoming stream was destroyed unless the session had an onstream callback, even when session-level stream callbacks (onheaders et al) were registered and the negotiated application (HTTP/3) would drive the stream through them. Users had to register stub onstream handlers just to keep their streams alive. Destroy an incoming stream only when the session has no consumer for it at all: no onstream callback, and no session-level stream callbacks runnable on the negotiated application (checked via the existing headersSupported session state, computed when the application is selected from ALPN). Sessions with no consumers keep the current destroy-and-warn behavior so unconsumed streams cannot accumulate and hold flow control credit. On HTTP/3 sessions only bidirectional request streams reach this path; control and QPACK streams are consumed internally by nghttp3 and are never exposed to JavaScript. Fixes: https://github.com/nodejs/node/issues/64192 Signed-off-by: Naman Trivedi <trivenay@amazon.com> PR-URL: https://github.com/nodejs/node/pull/65335 Fixes: https://github.com/nodejs/node/issues/64192 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Internal Modules
The modules located in lib/internal directory are exclusively meant
for internal usage within the Node.js core. They are not intended to
be accessed via user modules require(). These modules may change at
any point in time. Relying on these internal modules outside the core
is not supported and can lead to unpredictable behavior.
In certain scenarios, accessing these internal modules for debugging or
experimental purposes might be necessary. Node.js provides the --expose-internals
flag to expose these modules to userland code. This flag only exists to
assist Node.js maintainers with debugging internals. It is not meant for
use outside the project.