net: defer synchronous destroy calls in internalConnect by RajeshKumar11 · Pull Request #61658 · nodejs/node

Defer socket.destroy() calls in internalConnect and
internalConnectMultiple to the next tick. This ensures that error
handlers have a chance to be set up before errors are emitted,
particularly important when using http.request with a custom
lookup function that returns synchronously.

Previously, if a synchronous lookup function returned an IP that
triggered an immediate error (e.g., via blockList), the error would
be emitted before the HTTP client had set up its error handler
(which happens via process.nextTick in onSocket). This caused
unhandled 'error' events.

Fixes: #48771
PR-URL: #61658
Refs: #51038
Reviewed-By: Tim Perry <pimterry@gmail.com>
Reviewed-By: Jason Zhang <xzha4350@gmail.com>

Between onSocket and onSocketNT, the socket had no error handler,
meaning any errors emitted during that window (e.g. from a blocklist
check or custom lookup) would be unhandled even if the user had set up
a request error handler.

Fix this by attaching socketErrorListener synchronously in onSocket,
setting socket._httpMessage so the listener can forward errors to the
request. tickOnSocket removes and re-adds the listener after the parser
is set up to avoid duplicates. The _destroy path in onSocketNT is also
guarded to prevent double-firing if socketErrorListener already emitted
the error.

Fixes: nodejs#61658 (comment)

Between onSocket and onSocketNT, the socket had no error handler,
meaning any errors emitted during that window (e.g. from a blocklist
check or custom lookup) would be unhandled even if the user had set up
a request error handler.

Fix this by attaching socketErrorListener synchronously in onSocket,
setting socket._httpMessage so the listener can forward errors to the
request. tickOnSocket removes and re-adds the listener after the parser
is set up to avoid duplicates. The _destroy path in onSocketNT is also
guarded to prevent double-firing if socketErrorListener already emitted
the error.

Fixes: nodejs#61658 (comment)

Between onSocket and onSocketNT, the socket had no error handler,
meaning any errors emitted during that window (e.g. from a blocklist
check or custom lookup) would be unhandled even if the user had set up
a request error handler.

Fix this by attaching socketErrorListener synchronously in onSocket,
setting socket._httpMessage so the listener can forward errors to the
request. tickOnSocket removes and re-adds the listener after the parser
is set up to avoid duplicates. The _destroy path in onSocketNT is also
guarded to prevent double-firing if socketErrorListener already emitted
the error.

Fixes: nodejs#48771
Refs: nodejs#61658

Between onSocket and onSocketNT, the socket had no error handler,
meaning any errors emitted during that window (e.g. from a blocklist
check or custom lookup) would be unhandled even if the user had set up
a request error handler.

Fix this by attaching socketErrorListener synchronously in onSocket,
setting socket._httpMessage so the listener can forward errors to the
request. tickOnSocket removes and re-adds the listener after the parser
is set up to avoid duplicates. The _destroy path in onSocketNT is also
guarded to prevent double-firing if socketErrorListener already emitted
the error.

Fixes: nodejs#48771
Refs: nodejs#61658

Between onSocket and onSocketNT, the socket had no error handler,
meaning any errors emitted during that window (e.g. from a blocklist
check or custom lookup) would be unhandled even if the user had set up
a request error handler.

Fix this by attaching socketErrorListener synchronously in onSocket,
setting socket._httpMessage so the listener can forward errors to the
request. The _destroy path in onSocketNT is also guarded to prevent
double-firing if socketErrorListener already emitted the error.

Fixes: nodejs#48771
Refs: nodejs#61658

Defer socket.destroy() calls in internalConnect and
internalConnectMultiple to the next tick. This ensures that error
handlers have a chance to be set up before errors are emitted,
particularly important when using http.request with a custom
lookup function that returns synchronously.

Previously, if a synchronous lookup function returned an IP that
triggered an immediate error (e.g., via blockList), the error would
be emitted before the HTTP client had set up its error handler
(which happens via process.nextTick in onSocket). This caused
unhandled 'error' events.

Fixes: #48771
PR-URL: #61658
Refs: #51038
Reviewed-By: Tim Perry <pimterry@gmail.com>
Reviewed-By: Jason Zhang <xzha4350@gmail.com>

Between onSocket and onSocketNT, the socket had no error handler,
meaning any errors emitted during that window (e.g. from a blocklist
check or custom lookup) would be unhandled even if the user had set up
a request error handler.

Fix this by attaching socketErrorListener synchronously in onSocket,
setting socket._httpMessage so the listener can forward errors to the
request. The _destroy path in onSocketNT is also guarded to prevent
double-firing if socketErrorListener already emitted the error.

Fixes: #48771
Refs: #61658
PR-URL: #61770
Refs: #48771
Reviewed-By: Tim Perry <pimterry@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>

Between onSocket and onSocketNT, the socket had no error handler,
meaning any errors emitted during that window (e.g. from a blocklist
check or custom lookup) would be unhandled even if the user had set up
a request error handler.

Fix this by attaching socketErrorListener synchronously in onSocket,
setting socket._httpMessage so the listener can forward errors to the
request. The _destroy path in onSocketNT is also guarded to prevent
double-firing if socketErrorListener already emitted the error.

Fixes: #48771
Refs: #61658
PR-URL: #61770
Refs: #48771
Reviewed-By: Tim Perry <pimterry@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>

Defer socket.destroy() calls in internalConnect and
internalConnectMultiple to the next tick. This ensures that error
handlers have a chance to be set up before errors are emitted,
particularly important when using http.request with a custom
lookup function that returns synchronously.

Previously, if a synchronous lookup function returned an IP that
triggered an immediate error (e.g., via blockList), the error would
be emitted before the HTTP client had set up its error handler
(which happens via process.nextTick in onSocket). This caused
unhandled 'error' events.

Fixes: #48771
PR-URL: #61658
Refs: #51038
Reviewed-By: Tim Perry <pimterry@gmail.com>
Reviewed-By: Jason Zhang <xzha4350@gmail.com>

Between onSocket and onSocketNT, the socket had no error handler,
meaning any errors emitted during that window (e.g. from a blocklist
check or custom lookup) would be unhandled even if the user had set up
a request error handler.

Fix this by attaching socketErrorListener synchronously in onSocket,
setting socket._httpMessage so the listener can forward errors to the
request. The _destroy path in onSocketNT is also guarded to prevent
double-firing if socketErrorListener already emitted the error.

Fixes: #48771
Refs: #61658
PR-URL: #61770
Refs: #48771
Reviewed-By: Tim Perry <pimterry@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>

Between onSocket and onSocketNT, the socket had no error handler,
meaning any errors emitted during that window (e.g. from a blocklist
check or custom lookup) would be unhandled even if the user had set up
a request error handler.

Fix this by attaching socketErrorListener synchronously in onSocket,
setting socket._httpMessage so the listener can forward errors to the
request. The _destroy path in onSocketNT is also guarded to prevent
double-firing if socketErrorListener already emitted the error.

Fixes: #48771
Refs: #61658
PR-URL: #61770
Refs: #48771
Reviewed-By: Tim Perry <pimterry@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>

Between onSocket and onSocketNT, the socket had no error handler,
meaning any errors emitted during that window (e.g. from a blocklist
check or custom lookup) would be unhandled even if the user had set up
a request error handler.

Fix this by attaching socketErrorListener synchronously in onSocket,
setting socket._httpMessage so the listener can forward errors to the
request. The _destroy path in onSocketNT is also guarded to prevent
double-firing if socketErrorListener already emitted the error.

Fixes: #48771
Refs: #61658
PR-URL: #61770
Refs: #48771
Reviewed-By: Tim Perry <pimterry@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>

Between onSocket and onSocketNT, the socket had no error handler,
meaning any errors emitted during that window (e.g. from a blocklist
check or custom lookup) would be unhandled even if the user had set up
a request error handler.

Fix this by attaching socketErrorListener synchronously in onSocket,
setting socket._httpMessage so the listener can forward errors to the
request. The _destroy path in onSocketNT is also guarded to prevent
double-firing if socketErrorListener already emitted the error.

Fixes: #48771
Refs: #61658
PR-URL: #61770
Refs: #48771
Reviewed-By: Tim Perry <pimterry@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>

Between onSocket and onSocketNT, the socket had no error handler,
meaning any errors emitted during that window (e.g. from a blocklist
check or custom lookup) would be unhandled even if the user had set up
a request error handler.

Fix this by attaching socketErrorListener synchronously in onSocket,
setting socket._httpMessage so the listener can forward errors to the
request. The _destroy path in onSocketNT is also guarded to prevent
double-firing if socketErrorListener already emitted the error.

Fixes: #48771
Refs: #61658
PR-URL: #61770
Refs: #48771
Reviewed-By: Tim Perry <pimterry@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>