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.
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…):
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", ...)
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?
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 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.
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?
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.
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.
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.
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.