Repository navigation
Conversation
Read closes the connection with StatusInvalidFramePayloadData when the message cannot be unmarshalled, but its doc comment did not say so. Callers that retry in a loop then spin on a closed connection. State the behavior and point to c.Read plus json.Unmarshal for callers that want to keep the connection open.
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.
wsjson.Readcloses the connection withStatusInvalidFramePayloadData(reason "failed to unmarshal JSON") when the message can't be unmarshalled intov, but its doc comment doesn't say so. Callers who treat the returned error as per-message andcontinuein a read loop end up spinning on a closed connection, as reported in #399.This adds a paragraph to the
Readdoc comment that states the behaviour. For callers who want to keep the connection open, it points toc.Readfollowed byjson.Unmarshal.What this PR does not do: change the behaviour. The linked discussion asked whether
Readshould close at all. This PR only documents what it does today, as the issue asks.On js/wasm the close currently fails, because browsers reject 1007 (#575), so
Readonly returns the error there. #576 would send 1000 instead. I kept the comment to the native behaviour rather than describing that gap. Happy to add a js/wasm note if you prefer.Checked locally with a throwaway test (not included): over a
wstest.Pipe, sending{"a":1} junkmakeswsjson.Readreturn an error that wraps*json.SyntaxError. The peer then getsreceived close frame: status = StatusInvalidFramePayloadData and reason = "failed to unmarshal JSON".Fixes #450