I wanted to propose a few improvements that might be made to the SDK's Firestore Offline Persistence functionality.

To provide a little context, I work for a small organization using Firebase across 5 separate web applications (also wrapped as native applications through WKWebView and Android WebView) servicing about 2000 users. One of the main driving factors behind our decision to implement Firebase was the ease of implementing offline data access; it is very important to us.

Currently, there is an issue across most devices/browsers where Firestore can lose connection unexpectedly to IndexedDB and cannot recover without a restart ( #2711#2710#1533#1926#2581 ).

A comment from @schmidt-sebastian on the latest issue:

You should see this a lot less with SDK versions 7.2.1 and later. It does however seem that we were not able to completely solve this. If you do encounter this issue with the latest Firestore SDK, you will unfortunately have to reload your PWA/webpage or create a new Firestore instance.

We are exploring ways to re-architect our SDK to be more robust agains IndexedDb failures in general, but this will take us a bit of time.

I understand that this issue is being worked on and it is rather difficult to address as it might require re-writing a large part of the SDK. That said, for a product that is no longer in beta, it is unacceptable ti have issues that cause data loss and are unrecoverable (even if it happens "a lot less"). For our applications, we use a session recording software that allows us to recover data for a user when this happens based on their logs. But for a lot of people that are not aware this is happening (there is no warnings on the documentation that offline persistence is broken) this means permanent data loss.

Of course, there is always the option to disable offline persistence. But I do not think that is an option for everyone. For us at least, it is one of the major selling points of our apps.

While a fix is being worked on, these are some improvements I think could be made to the system that might not require a lot of work and would make everyone's lives easier.

1. Error Handling
   Currently, the only way to handle this error is to catch it at the Window level and then reload the page. The issue with this is that there is no way for me to know which of my .set() calls failed. When/if I reload the app, that data is still lost. Ideally, the error would (also?) be thrown to the original caller so that the application could easily identify which specific queries have failed. This would allow one to store the data manually and retry saving it when the app is reloaded.

2. Trigger Failure Manually
   Given that this issue is very difficult to reproduce consistently in a real-world scenario, I think it is important to add tools to the SDK so that developers can test their solutions inside of their actual apps instead of hoping that it will work when the failure happens in produdtion.

3. Notify Client When Going Offline
   We use onSnapshot calls to keep our clients up to date with data that might be inserted from another device. Obviously, these do not work when the user is offline. I would like to be able to notify my users that they are not receiving updates from other sources when they are offline. Right now, there is no way for me to know if Firebase is operating in offline mode, so I cannot notify my users of this.

4. Enable/Disable Offline Persistence
   Currently, offline persistence is disabled by default on the JS SDK. The only way to enable it is right after initializing the application. Perhaps that makes sense, but I would also like the ability to disable it at any point. A possible use case could be to allow a user to disable offline mode if they don't want to accidentally enter data that might be lost. Alternatively, they might leave it on if all they want is to access cached data for viewing only.

The last two points might not be directly related to the IndexedDB issue, but I still believe they are valid concerns/suggestions regarding the existing functionality for offline persistence.