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

Very simple to replicate:

// main.js
const ws = new WebSocket('wss://bleeding-imagine-scsi-ruled.trycloudflare.com'); // hosting this for ease of replication while this issue is debugged - see instructions below to host your own if needed

ws.addEventListener('open', () => {
  ws.send('a'.repeat(44351));
  console.log('Sent message.');

  ws.addEventListener('message', (event) => {
    if(event.data === 'success') {
      console.log('Got response.');
    }
  });
});
deno upgrade --version 1.33.0 # bug replicates in all later versions too, including latest (1.36.4) and canary
deno run --allow-net main.js

I’ve only tested on Ubuntu 22.04 - for me it hangs at “Sent message.” forever, about 80% of the time. If I drop the string length from 44351 to 44350, it works fine 100% of the time, and it also works fine on versions prior to Deno v1.32.5 and earlier. It also works fine if you paste the above code in the browser console (regardless of string length), of course.

If for some reason it works fine for you (e.g. it could be OS-version dependent), increase the string length to a high number like 1,000,000.

I’m hosting the referenced remote websocket server for ease of replication, but here’s the code in case you want to do it yourself. Note that the bug isn’t related to the server at all - I’ve replicated it with Node.js/Python/Deno WebSocket server across various runtime versions.

@bartlomieju @littledivy The above code is a much more minimal replication of the same problem I mentioned here:

Opening a separate issue because the bug seems distinct (different version cut-off), though it is perhaps related.

About this issue

  • Original URL
  • State: closed
  • Created 10 months ago
  • Comments: 17 (15 by maintainers)

Commits related to this issue

Most upvoted comments

Yep, that fixed it - thank you!!

@josephrocca I believe this might be fixed in the next canary. Would you mind re-testing once the canary for https://github.com/denoland/deno/commit/b75f3b5ca0952db8b50cf417c107f3f14fe582d5 builds?

There’s a few components to this – first is a fix in our V8 library that may have been causing issues in WebSockets in certain cases https://github.com/denoland/rusty_v8/pull/1326 (fixed).

Second, we need to split the read and write halves of the WebSocket to avoid potential undefined behaviour (https://github.com/denoland/fastwebsockets/pull/48 and https://github.com/denoland/deno/pull/20579).

Third, we need to upgrade our TLS support to a new TLS library here: https://github.com/denoland/deno/pull/20518

This is one of the things I’m actively working on, but I hope that I can get it across the finish line by next week (fingers crossed).

Early testing on the PR is definitely welcome. I’m currently blocked on my own work upstream in a new TLS library before I can merge this work, but it is possible you may be able to make things work. Backpressure is currently broken on my branch but otherwise should actually work.

Please let me know if that helps

@josephrocca we’re still debugging this problem. No ETA yet, but we’ll aim to fix it before v1.37.

@bartlomieju Yep, that’s correct - ws:// seems to work fine.

Thanks for the report 👍 that’s very detailed and useful. I assume the problem doesn’t happen on ws://, only on wss://? That would indicate problem in the integration with TLS library on our side.