v1.32.4 breaks web sockets

[caramboleyo]

For some reason server now only pushes at the same time the browser client pulls something.
i use wss, establishing connection works fine, server onMessage works fine, but after using send on the server it just waits and does nothing until next incoming.

by downgrading to 1.32.3 everything works normal again.

Sidenote: with firefox websockets are waaaaay slower than with chrome.

[bartlomieju]

This is already fixed by a411144

[caramboleyo]

meaning it will be in the next release?

[bartlomieju]

Correct, we will probably cut another patch release this week.

[caramboleyo]

Last deno version were websockets were working properly is still 1.32.3
All versions later have issues.

[bartlomieju]

@caramboleyo is there a reproduction code you could share that triggers this error?

[jespertheend]

I can reproduce this, but only on secure websockets.
I'll try to get a repro running.
edit: Ah seems like this was already mentioned.

[caramboleyo]

They replaced this bug with another:
#18977

[caramboleyo]

I made a complex testcase now:
https://github.com/caramboleyo/deno-websocket-bug

[josephrocca]

@bartlomieju @littledivy I just ran into something similar - v1.33.0 broke secure websockets - causes 20 second hangs when sending more than ~20kb of data in certain cases. Non-secure (ws://) still works fine for me.

EDIT: See a much more minimal replication here:

• Sending a string longer than exactly 44,350 characters over wss:// hangs indefinitely in Deno v1.33.0 and greater #20355

This script isn't particularly minimal, but it reproduces the problem I'm seeing: https://gist.github.com/josephrocca/ca159f837b351a9cd2dd31d728ed3ea9

As mentioned at the top of that file, just start the docker image, run cloudflared to proxy it to a https URL (no sign-up/account needed), alter the url variable in the script to match the one that cloudflared gives you, and run the script with deno run --allow-net main.js.

The script is 900kb but that's only because I'm sending a big jpeg data URL - it seems to more reliably reproduce if the string being sent is longer.

In 1.33.0 (and all later versions) you'll see at least a few "WARNING" logs indicating that the socket.send function took >5 seconds. Note that it will eventually send - it takes about 20 seconds, whereas it should take less than a second. In the prior version, 1.32.5 it works fine.

Equivalent node.js script works fine, for reference, but using npm:ws in Deno gives an unrelated error (not sure if npm:ws is supposed to be supported yet), so that's not a viable workaround right now (I personally can't downgrade to 1.32.5 because I'm relying on features that are only available in more recent versions of Deno).

[littledivy]

We're tracking the secure websocket bug in #20355. Closing this one.