-
-
Notifications
You must be signed in to change notification settings - Fork 134
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
Hocuspocus can crash on invalid WS payload (WS_ERR_INVALID_UTF8 or WS_ERR_INVALID_OPCODE) #418
Comments
hey @jamesopti, I've spent some time here and managed to identify a possible issue:
I'm working on a fix, I don't have a solution in mind yet but wanted to keep you updated on progress already. To make it more obvious, here's how you can reproduce it:
// Update: I'd assume it's also possible while onLoadDocument is running (just by looking at our code) |
@janthurau Thanks for sharing! This does seem like a good find/improvement. I'd have to thoroughly comb through our logs to see if this makes sense as the culprit for the instance where we saw the crash but nevertheless, this change feels like a good one. |
I've merged this, if you're still seeing this issue once you updated (release will go out soon), feel free to re-open! Thanks again or reporting this 😎 |
Description
We've started to see this error occasionally again in production that causes the Hocuspocus server to crash on a websocket error. Specifically, the error is:
#393 Attempted to fix this but it appears to still be possible. It's unclear to me how to catch this with certainty.
Steps to reproduce the bug
Unfortunately I'm not able to reproduce this yet. I tried sending some invalid websocket payloads to Hocuspocus but those appear to be filtered correctly.
Expected behavior
I would not expect ANY invalid websocket message from a single client to crash the server but rather log an error and close the offending connection.
Environment?
@hocuspocus/server@npm:1.0.0-beta.2
The text was updated successfully, but these errors were encountered: