Repository navigation
Conversation
WebSocket.close throws for any code other than 1000 and 3000-4999, so closing with the codes this package uses itself (1001 from CloseNow, 1008, 1009, 1011) failed and left the socket open, and under TinyGo the throw is a fatal panic. Send 1000 for those codes while keeping the requested code in the local close error, and stop the error handler from closing, since a close event always follows and waiting for it inside the callback deadlocks.
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
1 participant
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.
Fixes #575
WebSocket.closethrows for codes other than 1000 and 3000-4999. For those codes,exportedClosenow sends 1000 to the browser. The close error the caller sees still carries the code they asked for. The peer receives 1000 rather than, say, 1001, because the browser API has no way to send the others.The error handler also stops calling
closeWithInternal. Before this change that call always threw on 1011 and returned at once. With a valid code it would wait for the close event inside the error callback, and that event cannot be delivered while the callback blocks, so the program deadlocks. A close event always follows an error event, so recording the error is enough.TestWasmDialTimeoutcaught this.TestWasmCloseStatuscloses with 1001, 1008, 1009 and 1011 and fails without the fix. I ran the wasm tests under Node (its WebSocket applies the same code check) against a local echo server, three times, all passing. I did not run them under wasmbrowsertest.go vetpasses for both native and js, and the native tests pass.This does not handle a close reason longer than 123 bytes, which the browser also rejects.