Firebase return document not exist after clear cookies with IndexedDb persistence enabled.

[TrustyTechSG]

[REQUIRED] Describe your environment

• Operating System version: macOS 12.1
• Browser version: Chrome 105
• Firebase SDK version: 9.9.4
• Firebase Product: auth/firestore (auth, database, storage, etc)

[REQUIRED] Describe the problem

Firebase return document not exist after clear cookies with IndexedDb persistence enabled.

Steps to reproduce:

1. Create new Firebase authentication account and generate custom token from server environment.
2. Send token to client and sign in with custom token.
3. Write one document to /testing/document1
4. Get document /testing/document1, document is exists, everything correct.
5. Clear website cookies from Chrome address bar.
6. Repeat step 1 and sign in again.
7. Try get document at /testing/document1, return not exists (which if false).

This is only happening with enableIndexedDbPersistence enabled.

[hsubox76]

Can you clarify what "clear website cookies from Chrome address bar" means? Do you mean url params? Or do you mean clearing cookies with Chrome dev tools? Or do you mean selecting "Clear Browsing Data" from the Chrome 3-dot menu?

If it's the last choice it might be wiping all local storage, including IndexedDB. Then it's not able to find the document in the local cache. But not sure why it's not falling back to checking the Firestore backend, I guess I'll leave that for the Firestore team.

[cherylEnkidu]

Hi,

Can you provide code snippet you used to reproduce this behaviour?

[TrustyTechSG]

Can you clarify what "clear website cookies from Chrome address bar" means? Do you mean url params? Or do you mean clearing cookies with Chrome dev tools? Or do you mean selecting "Clear Browsing Data" from the Chrome 3-dot menu?

If it's the last choice it might be wiping all local storage, including IndexedDB. Then it's not able to find the document in the local cache. But not sure why it's not falling back to checking the Firestore backend, I guess I'll leave that for the Firestore team.

Hi there, I mean click the lock icon from Chrome address bar, select cookies, and then select website and click remove, once removed, onAuthStateChanged immediately called back with account = null.

Sorry I forgot to mention I did checked the metadata from the document, the document returned not exists with metadata fromCache: false, and from my Firebase console as you can see the document actually do exisits.

After step 7, even reload page not works, but, if i just add one line of code clearIndexedDbPersistence(getFirestore()), before enableIndexedDbPersistence(getFirestore()), then the return document will be correct again.

[TrustyTechSG]

Hi,

Can you provide code snippet you used to reproduce this behaviour?

`
const app = initializeApp({
apiKey: process.env.xxx,
authDomain: process.env.xxx,
databaseURL: process.env.xxx,
projectId: process.env.xxx,
storageBucket: process.env.xxx,
messagingSenderId: process.env.xxx,
appId: process.env.xxx
});

const appCheck = initializeAppCheck(app, {
provider: new ReCaptchaV3Provider(process.env.xxx),
isTokenAutoRefreshEnabled: true
});

// clearIndexedDbPersistence(getFirestore());
enableIndexedDbPersistence(getFirestore());

onSnapshot(doc(getFirestore(), testdocmentpath), fireDoc => {
console.log(fireDoc, fireDoc?.exists());
});
`

Please note as I tested, the test document path must be a path ruled to only be able to access by certain account, In my case I set rule to check on custom account metadata. So to reproduce this on your side, you must sign in with correct account first, load the protected document let it saved in local indexDB, and then clear cookies and sign in again, In my case, I signed in with another newly created account but with the same custom metadata (so same rights to access firebase), then I will have that wrong document status issue.

If only unmark the above line clearIndexedDbPersistence, and then this issue will gone.

[cherylEnkidu]

Hi,

With clearIndexedDbPersistence(getFirestore()); comment out, before you sign in the second time, if you refresh the page does this problem still exist? Also could you please share the user case scenario impacts by this issue?

[TrustyTechSG]

Hi,

With clearIndexedDbPersistence(getFirestore()); comment out, before you sign in the second time, if you refresh the page does this problem still exist? Also could you please share the user case scenario impacts by this issue?

Hi, because all my documents is protected by rules to limited to sign in account read only, so, you can not check the issue with out sign in first.

I agree there is no such use case, 99.99% of the user will not do clear cookies from the browser, but because once this happened, will leave some kind of bad status in IndexDb and even refresh page not be able to solve it, so the effected user will be blocked from using the site, which I think is significant.

[cherylEnkidu]

Thank you for your context and spending time help us reproduce this problem! We have reproduced it and captured it to the backlog (b/249145220). However given the rare case, we won't prioritize fixing this. Thank you again for your understanding.

[fypmvip]

I am experiencing the same issue when the user clears their recent browsing history in Chrome. For us, the impacted user is also blocked from using the entire site. For us, it is with enableMultiTabIndexedDbPersistence enabled.

[cherylEnkidu]

Hi @fypmvip ,

Could you please file another ticket for your issue and provide detailed reproduce steps?

[cherylEnkidu]

Hi,

This feature is been tracked internally, I will close this github ticket and reporter will be notified in the future when the feature gets implemented.

[cherylEnkidu]

Hi,

The team decided to keep the ticket open until the feature is implemented or bug is fixed for external visibility.

[lirantzairi]

Hi @cherylEnkidu , @hsubox76
We're experiencing the same issue in our product and it's become serious. Clearing a site's cache isn't that uncommon, users do it. It happened to some of our bigger clients and it completely prevented them from using our app. Any plans to fix this or at least give us a workaround? Thanks

[entrenadorhispano]

Same here, Guys this is a very concerning problem for production apps.

We are just not going to be able to use persistence until it is fixed.
This bug may severely impact the user experience on any web app .

Please check it again...