Status update:

• We do, in fact, have options for testing the websocket connections via integration tests, but they got a little too convoluted relative to the amount of code changes the frontend needed. It's something that we can consider in the future, and I added some comments to minimize the risks of wild goose chases if someone tries again, but for now, I think we can skip things
• The wrapper class has been updated, and has full type-safety
• All the API calls have been updated to the new backend routes. Not 100% sure that the names are what we want to go with, but that's something that can easily be fixed in review
• Only marking this as blocked because I need the backend changes wrapped up before I do the stress-testing
• While I was making updates, I ran into a few other long-standing bugs and got those fixed up, too

Truth be told, if I knew for a fact that WebSocket integration tests weren't worth it, this could be a Complexity 1. But this was a case where it felt prudent to see what we could do to add tests, since the issues are all in service of fixing a problem being faced by multiple customers

Wouldn't the server sent events be better than web sockets if only sever -> client one way connection is needed.

@alihammad-gist You would think so, but there's actually a problem inherent to SSEs that doesn't exist with WebSockets. SSEs are still based on HTTP, so when the protocol is HTTP/1.1, it's still grouped with normal one-time server requests. And since browsers only allow 2–6 active HTTP connections per domain at a time, all you have to do is open Coder in multiple tabs, and that can cause the entire app to lock up

WebSocket connections are still initiated via HTTP on HTTP/1.1, but because the connection type changes afterwards, browsers have much, much better multiplexing support

To illustrate how different they are, I was able to set up 700 WebSocket connections for a single domain on HTTP/1.1 (100 connections per seven tabs), and there was zero issues. When I had seven SSE connections open (whether that was one connection per seven tabs, or seven connections all in the same tab), they all locked up

It'd be nice if we didn't need these workarounds, but the SSE protocol is very old, and wasn't really made to handle these things. There's a reason why SSEs have warnings on their MDN documentation pages, while WebSockets don't