Repository navigation
Conversation
Member
|
You should not use the wrapped |
This branch has not been deployed
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Calling
WebSocket.terminate()destroys the underlying socket without necessarily finishing its writable side. If the wrapped Duplex is then ended,_final()waits for a socketfinishevent that cannot occur, leaving its end callback and writablefinishpending.Complete the finalizer when the socket is already destroyed. Also check both readable end and writable finish from either event, so the Duplex closes after both halves complete regardless of event order and preserves unread buffered data. The existing failed-handshake guard and finalizer callback ordering are retained.
Six real TCP client/server regressions cover CLOSED and CLOSING states, readable end before writable finish, buffered data, and
allowHalfOpen: false, including exactly-once lifecycle events and end callbacks.Validation on exact commit
51510804a47dfc010983bc802706f5bb0d2dd599:npm test, and both ws/wss echo integrations. Full Node 10/24 optional-addon fallback suites and unchanged ESLint/Prettier checks pass. The aggregate run is red because its direct Mocha CLI invocation fails before tests on Node 26.npm testpasses 438 cases; exact formalnpm testpasses 444, the six regressions and original four probes pass, andlib/stream.jshas 100% coverage. Both trees have the existing single HTTP-header test skip. Barenpm run integrationfails before tests in both trees because legacyyargs/yargsis loaded as an ES module; executing the same two real integration files through the project's unchanged nyc/Mocha loader passes on both. No dependency, package-script, or CI change is included.Source hashes and clean working trees are checked before and after native validation.