WebSockets timeout and long wait time before fallback to long polling

[benjarwar]

Describe your environment

• Operating System version: Mac OS X Sierra
• Firebase SDK version: 4.10.1
• Firebase Product: database

Describe the problem

When instantiating my Firebase app and making the first database call, I'm seeing occasional (but consistent) WebSocket connection failures. It occurs about one out of every 10-20 page loads, and looks like this:

WebSocket connection to 'wss://s-usc1c-nss-214.firebaseio.com/.ws?v=5&ns=foo' failed: WebSocket opening handshake timed out
WebSocketConnection.js:122

I have already contacted support, and, after a lengthy correspondence, have been told that this is likely due to internet traffic. But I've been reproducing the issue consistently for many weeks. And, because my app requires a Firebase connection before the user sees any content, constitutes a really bad user experience when it occurs.

My only option at this point is to force Firebase to use long polling before instantiating the app. But in the words of my Firebase support contact, "that would degrade service in all cases over the percentage that have connectivity issues".

I'd like to suggest two possible solutions:

1. Decrease the maximum wait time before Firebase gives up on WebSockets and falls back to long polling (perhaps 5-10s instead of 20-30s), or...
2. Provide a method for switching to long polling after the Firebase app has been instantiated. Then, developers can run their own timers and make the switch manually at their discretion.

Steps to reproduce:

I can reproduce this issue consistently approximately one out of every 10-20 page loads on any Firebase application, including the test connection page. Here's a screenshot of one such failure:

See also this StackOverflow issue where other users are reporting and concerned about similar behavior.

[google-oss-bot]

Hmmm this issue does not seem to follow the issue template. Make sure you provide all the required information.

[mikelehen]

Thanks for the detailed feedback.

I'm unfortunately not able to reproduce this against https://www.firebase.com/test.html (I refreshed 50 times and each time it completed in <1 sec, usually < 0.5 sec). So I'd be curious to know if you've been able to reproduce using different network connections (perhaps there's a buggy router / proxy / whatever in your route to Firebase) or verify that users of your app are experiencing this as well. I'm also curious if you've confirmed that forcing long-polling 100% resolves the issue.

As for the timeouts, I'd be hesitant to change them since on a low-signal mobile network, 5-10 seconds may not be long enough (and in general tweaking these timeouts is somewhat risky).

Out of curiosity, have you tried calling firebase.database().goOffline() followed by firebase.database().goOnline() when your timer detects it's taking too long to establish the connection? I'm not certain, but that may be enough to get it to fall back to long-polling (the SDK will prefer long-polling if the most recent WebSocket attempt did not succeed).

Sorry for the pain. Hope this maybe provides some help.

[benjarwar]

Thanks for the advice and testing, @mikehaney24. I did have one of our other devs test our application, and he reported a >30s timeout during one of his refreshes (although he didn't see the same error I did). As mentioned, there seems to be other users experiencing similar behavior in this StackOverflow question. In my testing, switching to forced long polling definitely fixes the issue in my app.

I get your point about the riskiness of reducing the timeouts, but still think it'd be nice to expose this option to developers. If we can already force long polling entirely, why not give us control over when Firebase makes the switch? Seems like it's less of a hammer drop, as we wouldn't be penalizing all users for the minority with connection issues.

I haven't tested goOffline and goOnline. It sounds like a possible solution, but have concerns about potential race conditions between the client and Firebase. Would in-flight requests be returned safely if Firebase access is toggled? I also have event listeners bound to authentication, and would need to ensure that they don't fire additional times, and/or that the callback methods are properly idempotent.

[mikehaney24]

I think you might've meant @mikelehen?

[benjarwar]

Sorry for the bother, @mikehaney24. Finger slipped on the autocomplete!

[mikelehen]

Unfortunately these timeouts probably aren't good candidates for exposing via public APIs since they are internal implementation details and we may change their behavior (or remove them entirely) over time. Changing the timeouts could also potentially have undesirable effects on our backend servers if tuned improperly. It would also be extremely hard to document how developers are expected to use them.

That said, there's a reason we made the clients open source. If you feel that tuning these timeouts is going to lead to a better user experience for your app, feel free to give that a try. And I'd be interested to hear the results (if it increases or decreases connection latency across your user base, etc.).

[skopanev]

HI all! Did you solve this issue? We still have this problem.

[mwood23]

Any updates on this one? I'm running into this using Expo and it's really wrecking my app. Happy to help make a fix if anyone can point me in the right direction.

[imanbee]

we tried this on app initialisation

for (var key in localStorage) {
    if (key.includes('firebaseio.com')) {
      localStorage.removeItem(key);
    }
}

and it resolved the problem

[glauberramos]

@imanbee do you run this code always for all users?

[imanbee]

@imanbee do you run this code always for all users?

yes, exactly

[maneesht]

Closing as this may have been solved in Chrome itself. Please reopen if you're still having issues.