Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RangeError: Invalid WebSocket frame: RSV1 must be clear #2019

Closed
1 task done
richconner opened this issue Mar 8, 2022 · 7 comments
Closed
1 task done

RangeError: Invalid WebSocket frame: RSV1 must be clear #2019

richconner opened this issue Mar 8, 2022 · 7 comments

Comments

@richconner
Copy link

Is there an existing issue for this?

  • I've searched for any related issues and avoided creating a duplicate issue.

Description

node:events:498
throw er; // Unhandled 'error' event
^

RangeError: Invalid WebSocket frame: RSV1 must be clear
at Receiver.getInfo (/home/ubuntu/server/node_modules/ws/lib/receiver.js:189:14)
at Receiver.startLoop (/home/ubuntu/server/node_modules/ws/lib/receiver.js:136:22)
at Receiver._write (/home/ubuntu/server/node_modules/ws/lib/receiver.js:83:10)
at writeOrBuffer (node:internal/streams/writable:389:12)
at _write (node:internal/streams/writable:330:10)
at Receiver.Writable.write (node:internal/streams/writable:334:10)
at Socket.socketOnData (/home/ubuntu/server/node_modules/ws/lib/websocket.js:1231:35)
at Socket.emit (node:events:520:28)
at addChunk (node:internal/streams/readable:315:12)
at readableAddChunk (node:internal/streams/readable:289:9)
Emitted 'error' event on WebSocket instance at:
at Receiver.receiverOnError (/home/ubuntu/server/node_modules/ws/lib/websocket.js:1117:13)
at Receiver.emit (node:events:520:28)
at emitErrorNT (node:internal/streams/destroy:157:8)
at emitErrorCloseNT (node:internal/streams/destroy:122:3)
at processTicksAndRejections (node:internal/process/task_queues:83:21) {
code: 'WS_ERR_UNEXPECTED_RSV_1',
[Symbol(status-code)]: 1002
}

ws version

No response

Node.js Version

No response

System

No response

Expected result

No response

Actual result

No response

Attachments

No response

@richconner
Copy link
Author

I am reporting this on behalf of my development teammate, Consty.

We have a send() function in a try/catch block,
We also process the "error" event

@lpinca
Copy link
Member

lpinca commented Mar 8, 2022

Add a listener for the 'error' event on the WebSocket instance.

wss.on('connection', function connection(ws) {
  ws.on('error', console.error);

  // ...
});

@lpinca lpinca closed this as completed Mar 8, 2022
@lpinca
Copy link
Member

lpinca commented Mar 8, 2022

See also #1777, #1825, etc.

@suinswofi
Copy link

suinswofi commented Mar 9, 2022

Add a listener for the 'error' event on the WebSocket instance.

wss.on('connection', function connection(ws) {
  ws.on('error', console.error);

  // ...
});

We process the error, but I think there was a race condition due to using an async function for the connection event and calling await on another call. See example below. May want to handle error silently if one isn't already attached to the websocket.

wss.on('connection', async function connection(ws) {
  await myfunction();   

  // this event isn't attached until after myfunction finishes, and if an error occurs before myfunction finishes, it will crash the library
  ws.on('error', console.error);

  // ...
});

@lpinca
Copy link
Member

lpinca commented Mar 9, 2022

May want to handle error silently if one isn't already attached to the websocket.

No, the process must exit if an error is emitted and there is no listener for the 'error' event as per https://nodejs.org/api/events.html#error-events.

@suinswofi
Copy link

May want to handle error silently if one isn't already attached to the websocket.

No, the process must exit if an error is emitted and there is no listener for the 'error' event as per https://nodejs.org/api/events.html#error-events.

Understood. My recommendation then would be to update your documentation to be careful when using async functions attached to ws events (specifically connection) since a race condition exists that will effectively crash the entire program. All the discussions I've seen state that it's safe to use them, but definitely not for the connection event at a minimum. That's what was killing us.

@lpinca
Copy link
Member

lpinca commented Mar 15, 2022

All the discussions I've seen state that it's safe to use them, but definitely not for the connection event at a minimum.

It's ok. You only have to add the listener of the 'error' event before any await.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants