Promises returned by doc().get() sometimes stop getting resolved if persistence is enabled

[optimistiks]

Describe your environment

• Operating System version: macOS Catalina 10.15.4 (19E287)
• Browser version: Safari Version 13.1 (15609.1.20.111.8)
• Firebase SDK version: 7.14.5
• Firebase Product: firestore

Describe the problem

In our app, we've discovered that sometimes when you request documents from a collection in quick succession, the documents just stop loading. The promises returned by SDK (doc(id).get()) just stop getting resolved, then callback never fires, and neither does catch.

Steps to reproduce:

It is a very hard to replicate issue.

We've discovered that the issue happens only with enabled persistence. So we've created a codesandbox to reproduce.

https://xqwkf.csb.app

You will see a button. This button loads a document from a collection, using a random id. Normally, when you click it once, you will see 2 logs in the console - START, meaning request is started, and FINISH, meaning promise is resolved, and the document is retrieved.

However, if you click this button fast enough, the promises stop getting resolved. You will only see START logs, and no FINISH logs.

It replicates only sometimes. We couldn't pin point the exact 100% steps to reproduce. So I'm attaching a gist where you see the logs from the console (Firestore debug logs included) from one of the successful attempts. You can search for "POI:" in that gist to find the place when it stopped working. Gist: https://gist.github.com/optimistiks/6176952eff312fba981c0c8d90254639

Relevant Code:

https://codesandbox.io/s/busy-mendel-xqwkf. The code for the above example. Note that it won't work in the codesandbox preview, you need to open it in a separate tab using this link https://xqwkf.csb.app.

[rafikhan]

Hi @optimistiks, thanks for taking the time to compile the logs and code samples together. These were super helpful to understand your situation.

I used the the link you sent me, rapidly clicked the button a few separate times on different machines and browsers and so far I haven't hit the issue you described.

1. How often are you seeing this happen?
2. Are users hitting this or is this just during development?
3. Are you using this in a desktop or mobile browser or an environment like electron?
4. I noticed your code sample has synchronizedTabs set to true. When you see this do you have different tabs open using Firestore?

[optimistiks]

Hi @rafikhan ,

Are users hitting this or is this just during development?

We have several reports from our users, but it seems like due to the nature of the issue, some users are completely unaffected. It reproduces during development as well, both when using the full emulator suite, and when connecting to the actual Firebase project.

How often are you seeing this happen?
Are you using this in a desktop or mobile browser or an environment like electron?

We've just run some more tests with my colleague. We were able to reproduce the issue on our staging and production builds in the following browsers:

• Desktop Safari Version 13.1 (15609.1.20.111.8), macOS 10.15.4 (19E287).
• iOS 13.4.1 Safari.

We were not able to reproduce it in Chrome. In my first message I said we could, but it was some misunderstanding. Seems like this issue is Safari-only.

I noticed your code sample has synchronizedTabs set to true. When you see this do you have different tabs open using Firestore?

We do have this flag set to true, but we've used a single tab only for debugging. That being said, we were able to reproduce the issue with the flag set to false, as well as with the default cacheSizeBytes. Only when persistence is disabled the issue completely goes away.

[schmidt-sebastian]

@optimistiks Thanks for reporting this and for responding to @rafikhan's questions. I will take a look at this, but will probably not be able to get back to you until Monday or Tuesday.

[schmidt-sebastian]

@optimistiks How often do you need to press the button to reproduce?

I am testing on Desktop Safari 13.1 and everything works for me. We have issues in the past when multiple hundreds of queries are pending. I wonder if this might be the problem you are hitting.

[wallaceturner]

I am seeing this problem as well. My environment:

• Operating System version: 13.4.1 mobile
• Browser version: Mozilla/5.0 (iPhone; CPU iPhone OS 13_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Mobile/15E148 Safari/604.1
• Firebase SDK version: 7.14.4 (also 7.9.1)

my code is fairly simply -

const ref = database.collection("surveys").doc(survey.id);
const doc = await ref.get();
if(doc.exists)
    ref .update(updates)
else
    await ref.set(survey)    

Eventually the code hangs on the await ref.get() call - no other calls work on the api - that is the entire firebase api is stuck until you refresh - it is fairly easy to recreate - you just need to call code similar to the above 1 to 100 times.

The behaviour seems to only occur when you havee the enablePersistence call on init

firebase.firestore().enablePersistence()

I have not seen this occur when I remove enablePersistence so I suspect they are related.

Can you please advise? I will try and get an easier recreate however you have one above from @optimistiks - are you able to try this on a mobile device? This bug is a bit of huge blocker for me - i have unfortunately had data loss for a client due to not awaiting the result of the save operation. :(

[zemfr]

@wallaceturner Do you use onAuthStateChanged before it? I have pretty similar situation if I do it.
Bug is reproduced in Safari on IOS 13.4.1. I thought that problem is related to framework which I use but It is reproduced for example from official documentation.
It is not easy to reproduce. But it is really annoying.

1. User received the link in a messenger and opens it;
2. User doesn't wait when onAuthStateChanged is done first time (it can be less than 1 sec) and returns to messenger or just change the tab;
3. User locks/unlocks iPhone;
4. User tries open the link again (it opens in new tab) but onAuthStateChanged never resolves. Firestore query also has pending status and never resolves, if I use it after onAuthStateChanged.
   If user closed current tab and returned to previous one, then page works well.

[wallaceturner]

onAuthStateChanged

@zemfr all my queries are done after onAuthStateChanged - in fact the app isnt rendered until the callback of this method is invoked.

[zemfr]

I just tried to reproduce without onAuthStateChanged, only with firestore query and I also get this bug. I use the same scenario that I described. But I noticed that I can't reproduce it, if I remove firebase-auth script from the page
<script src="https://www.gstatic.com/firebasejs/7.14.6/firebase-auth.js"></script>.
Of course I'm not sure 100% that it influences on it but I haven't reproduce this bug without auth script.

[schmidt-sebastian]

@wallaceturner / @zemfr Firebase Auth is also using IndexedDb by default. I wonder if the SDKs are stepping on each other toes here.

@avolkovi Have there been reports that the Auth SDK ends up blocking IndexedDB access?

[wallaceturner]

@schmidt-sebastian what useful information could i provide? i could give you the stack possibly where it is blocked

[schmidt-sebastian]

@wallaceturner I cannot promise that just looking at the stack will help, but I would love to see it. FWIW, we are currently rewriting the Auth client from scratch. I suspect you can work around this issue in the meantime by disabling IndexedDB access in Firebase Auth. I have to admit that I don't know how to do this though.