WebSocket is closed before the connection is established

I’ve got an issue with an app and I’ve no idea of how to troubleshoot it. I’m hoping someone here might have seen something similar.

I pushed out an update to a test app, and now when i browse to it, it’s stuck in a cycle trying to connect to the web socket. The static content is displayed, the browser tries to connect to the web socket, it times out and repeats the cycle.

I have seen this in the development environment too very intermittently (like twice). I thought it might be something to do with the code reloader, because as soon as I switched that off in dev, the problem went away.

Any ideas about where to start looking?

Also, it seems confined to a browser session. ie, I can browse to the same app in a different browser and it works fine… So with that in mind, I cleared cookies on the failing instance, crossed my fingers… but still no good.

I have more info, but I’m not sure how significant it is! The connection came good, for no apparent reason. I’m trying to work out why. When comparing two adjacent websocket calls in dev tools (the last failing call, and the first successful one), the only obvious difference is regarding the time of the message. The failing call (says it was stalled for 5.3 days? Actually, hovering over the the time on the failing call, it says 06/01/1970 16:24…):

And the next call, that was successful:

Are you using brave by any chance?

1 Like

Wow, how did you know?! It was in the back of my mind that Brave might be the culprit… I wasn’t seeing the same thing with Chrome

This is the third report I have seen with Brave hanging in the 101 websocket upgrade. Unfortunately it doesn’t appear to be anything on our side and by all things I’ve seen the bits never make it to the server. One person had it happen only when the adguard extension was enabled, but disabling didn’t fix it until they restarted Brave. Both previous reports I’ve seen restarting Brave fixed it, but this looks like some obscure issues squarely on Brave’s side. I have wondered if we are attempting to connect too aggressively for brave, but it is a total guess. If you are able to reliably recreate, you could try instantiating the liveSocket and liveSocket.connect inside a window.addEventListender("DOMContentLoaded", ...)

5 Likes

from a very quick look it seems like Brave proxies websocket when the shield is “up”… through this code: brave-core/brave_proxying_web_socket.cc at master · brave/brave-core · GitHub (and probably else where for the 101 upgrade - NOT a C expert)

there was a recent commit to that file fixing a bug 15715: Properly shutdown our websocket proxy. · brave/brave-core@79783d3 · GitHub, slated for next major brave version (1.26) but totally unknown if it fixes anything related to this issue…

but does sound plausible that some issue exist with brave, especially when using the shield ws proxy… maybe it can be sporadically reproduced running 100-1k tests with wallaby/chromedriver?

1 Like

Thank you both, that’s great news (for me!), I thought I was entering a world of pain trying to work out why my app was misbehaving.

I’ll continue to use brave and try a couple of things when it next happens. It appears to only happen when something updates on the server - once in production after I pushed a new release, and a couple of times in dev when the code reloader kicked in. It seems to right itself after about an hour for no reason (yesterday I gave up trying stuff, then came back after 20 mins, and it was all good).

I’ll fire up wireshark next time and see if i can see anything on the wire.

I use Brave get that when I have forgotten to close a div or something. I thought it happened on Edge too though…

I have a control panel which has two domains point at it and I see these a lot in Chrome when I have tabs open with both domains. If all my tabs are 1 domain or the other it’s fine but as soon as there is a mix all liveview pages start to fail.

Just wanted to check in and say I’m still encountering the same endless reloading “websocket connection is closed before connection is established” issue.

I’m using Brave 1.28.105 on MacOS 11.5.1 and looking at the source code for this version of Brave on Github, the previously linked PR’s websocket fix code is present in this version of the browser but it doesn’t seem to make a difference.

I still get the Websocket error with or without Brave’s “shields” up or not.

1 Like

Hi @jakemauer, that’s interesting, I’ve not had it happen to me since I posted. For me it’s been really intermittent. Is it happening for you all the time?

I’m on the same version of Brave, but on linux

Yeah it happens predictably but not deterministically with our Phoenix app. I can often enter a state of infinite reload within 30s of clicking around. But sometimes it happens right on first page load, and I don’t have any other open tabs to the same app.

Yeah, sounds similar, but you’re seeing it a lot more frequent than I was experiencing. Are you seeing it in both prod and dev? You’ve ruled out other browsers? You’re not seeing any errors in the server during the loop?

It’s pretty frustrating, because I couldn’t consistently trigger it. All I did find is that in dev, disabling the Endpoint code_reloader in dev.exs seemed to stop the cycle. Also, in prod, it came out of the cycle for no apparent reason after about 60-90 minutes. But that could all be coincidence.

If you can trigger it reasonably consistently, this might help track down the issue?

1 Like

So I’ve now tried wrapping the new LiveSocket... and liveSocket.connent() code in window.addEventListener(“DOMContentLoaded”) and no dice. I still get websocket errors and reloads.

I think it’s this issue WebSocket sometimes fails to reconnect until browser restart or website access from incognito mode · Issue #15410 · brave/brave-browser · GitHub
Linked issue Hasura WebSocket closed before connection is established error while trying to create subscription · Issue #4509 · hasura/graphql-engine · GitHub sounds very similar to this problem.

1 Like

Just chiming in; I’ve been experiencing this in latest Brave stable and on LiveView 0.17.7. I have not tried wrapping on the DOMContentLoaded EventListener yet…

I would avoid using that browser until its fixed. Because WebSockets are used quite a bit in many pages. If you are making a WebSocket using website I would detect Brave browser and give people warning about this issue until they fix it.

Is anyone aware if this is still an issue with Brave in general?
I’ve been running Phoenix on localhost in Brave (with shields down) and it seems to fall back to long polling after the first websocket response. I’m not sure if this is just a localhost issue or not, but it works fine in Chrome.

I’m no longer using Brave, but I only had the issue happen a couple of times, then never again.

Your sticking to longpoll issue sounds like something I’ve experienced (with chrome). I posted about it here LiveView falls back to longpoll after dev server restart

Basically, websocket is used in dev environment until I kill the dev server and restart. After that any existing browser tabs connected to the server will use longpoll, but new browser sessions use websocket.

1 Like