net: deferred self.destroy calls in internalConnect(Multiple) to next… by timothyjrogers · Pull Request #51038 · nodejs/node
… tick self.destroy calls in the internalConnect adn internalConnectMultiple functions have a narrow case where they can throw before an error handler has been established. This change defers them to the next tick to allow time for the error handler to be set. Fixes: #48771
labels
nodejs-github-bot pushed a commit that referenced this pull request
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>
aduh95 pushed a commit that referenced this pull request
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>
aduh95 pushed a commit that referenced this pull request
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>
aduh95 pushed a commit that referenced this pull request
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>
aduh95 pushed a commit that referenced this pull request
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters