RFC: Usage of experimentalForceLongPolling option.

[mikelehen]

Are you experiencing the error Could not reach Cloud Firestore backend. Backend didn't respond within 10 seconds despite your network seeming healthy? Please visit https://debug-my.firebaseapp.com/ and check the results at the end. If the tests "with default options" fail (or are very slow) but the "with forceLongPolling" ones succeed, then this indicates your traffic is likely going through a proxy that is buffering responses in a way that is not compatible with Firestore.

As a workaround, you can force long-polling as follows:

firebase.firestore().settings({ experimentalForceLongPolling: true });

Have you enabled experimentalForceLongPolling and experimentalAutoDetectLongPolling to solve a reproducible connection issue related to a specific environment?

We would like to know:

1. What environment causes the problem (app platform, antivirus software, network proxy, network conditions, etc.)?
2. What is the behavior without experimentalForceLongPolling or experimentalAutoDetectLongPolling?
3. Does experimentalAutoDetectLongPolling completely resolve the issue?
4. Does experimentalForceLongPolling completely resolve the issue?
5. Please visit https://debug-my.firebaseapp.com/, wait for "All tests done" (about 60 seconds), paste the results into a gist, and paste the link in your comment.

If there is an existing comment concerning the environment you are using, feel free to just add a 👍 to it.

[tgangso]

Hi,

I was going to enable this feature because it describes an issue that sounds similar to what many of my users are describing when using my app on corporate networks.

But from my testing this results in an absurd amount of network requests when querying large (5- 10000+ documents) collections (using "@angular/fire": "5.1.2" + "firebase": "5.10.0", with enablePersistence), it looks like it gets one channel request for every document in the collection, causing very long loading times waiting for the result. And I found it unusable in its current state and have deactivated it again. After deactivating I am back to normal amount of network requests (1 for the collection).

Hope it can be improved as many users report issues that sounds like this feature would fix.

[mikelehen]

@tgangso Thanks for the feedback! (and sorry it didn't work out for you). We'll discuss to see if we can do anything about the performance. In the meantime, were you able to determine if this solved any issues for your users? And if so, can you comment more on the corporate network environment that was causing issues? Thanks.

[tgangso]

@mikelehen I have not been able to reproduce the issue myself, but generally users on Equinor/Statoil corporate network experience the issue, also some users with adblocker (VPN based i think) have reported this.

I never deployed the setting to production because of the performance issues, so I am unable to confirm if it helps or not, but I have some users that can help testing when/if performance is improved.

[tgangso]

I did end up adding an option for the user to enable this manually, and have asked a few users to try it out, and it did indeed help with the issue, and they where able to use the application.

So I hope this option is not removed, as it will help even if performance is lower. Not all my users have huge amount of documents.

One user had issues on his Mac, same network as his phone (where it works). gist.

One user is on a "high security" corporate network, gist.

Behaviour without experimentalForceLongPolling, is no data is retrieved or being sent to firestore, but works when enabled.

Hope it helps.

Maybe it could be possible for firebase-js to detect when this is needed as a fallback?

[tgangso]

Added a gist for the mac scenario also.

Let me know if you want me to test anything else.

[mikelehen]

@tgangso Thanks very much for the data. We'll plan to keep the option around unless the problem stops happening or we devices a better solution (like automatic fallback).

[tgangso]

@mikelehen great, I can confirm a few others have tried the setting with success. Automatic fallback would be great if possible.

[mikelehen]

@tgangso FYI- There was a backend change that should cut down on the number of network requests when using this option. Would you be interested in trying it again and reporting on whether it behaves better now?

[tgangso]

@mikelehen i did some quick testing now, and it definately feels better, looks like there are more documents per request now. Will keep the setting on for a bit and test.

[rodrigoreis22]

We're looking into adding this as a fallback for our web application. Some small percentage of users get the message Could not reach firestore backend and we're using the latest sdk version.

Is it possible to enable this setting after the app is already initialized only in case of a failure reaching the firestore backend? Ideally I want to enable this only on a catch flow .

[mikelehen]

@rodrigoreis22 Not super easily. But you can call firebase.app().delete() and then call firebase.initializeApp(...) again, and then firebase.firestore() will return a brand new instance which you can call .settings({experimentalForceLongPolling: true}) on... but note that any existing writes / listeners / etc. will need to be reestablished.

[dubvi5]

Hi. I cannot connect to firestore without experimentalForceLongPolling.

1. Windows, on a corporate network with McAfee endpoint security.

2. On first load I get "Could not reach Cloud Firestore backend. Backend didn't respond within 10 seconds.", but it works if I reload the page.

3. experimentalForceLongPolling seems to completely resolve the issue.

4. https://gist.github.com/dubvi5/1731f17940531d94451aeded761d08ad

Thanks.

[dcc82]

Hello, we have a Firestore connection issue with one of our computers at work. The error message says "Firestore (6.3.0): Could not reach Cloud Firestore backend. Backend didn't respond within 10 seconds..."

This issue doesn't occur on the other computers within the same network. Enabling ExperimentalForceLongPolling seems to resolve the issue.

The problematic one is a Windows PC with "Symantec Endpoint Protection" installed. The others are all Mac computers without antivirus.

Here's the gist: https://gist.github.com/dcc82/270cc8eac2f0fe312aa4ac8befad7925

Thanks.

[bhar4t]

Hi

I enabled the feature and I tried feature enabled project with online, mid-range mobile and low-end mobile network options of chrome debugger.

I still getting error message as "Firestore (6.3.0): Could not reach Cloud Firestore backend. Backend didn't respond within 10 seconds..." in only on low-end mobile. except both is working fine in the both condition whether with feature enabled or not.