You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I’ll say right away that the bug is floating and I don’t have a ready-made recipe for reproducing it. The bug usually appeared during debugging. Apparently, timings and the sequence of data arrival are important. The server should also send pings to get this effect.
From the screenshot you can see that the websocketMessageReceived function is called with this.#info.originalOpcode=9 (PING frame type), which should not happen.
Logs & Screenshots
Environment
node v21.6.2
The text was updated successfully, but these errors were encountered:
Yes, I only encountered this error in debugging. But, I assume that the problem is not related to it, but to the timings. Before null in the message handler received, two breakpoints are triggered. But if you send a ping from the server with a little delay (calling process.hrtime() before sending is enough), then everything goes fine.
FWIW, I definitely encountered this bug outside of debugging. The WebSocket would receive messages correctly for a while and then it would always give me nulls.
Bug Description
I’ll say right away that the bug is floating and I don’t have a ready-made recipe for reproducing it. The bug usually appeared during debugging. Apparently, timings and the sequence of data arrival are important. The server should also send pings to get this effect.
From the screenshot you can see that the
websocketMessageReceived
function is called withthis.#info.originalOpcode=9
(PING frame type), which should not happen.Logs & Screenshots
Environment
node v21.6.2
The text was updated successfully, but these errors were encountered: