Offline Mode Improvements #2755
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.
A comment from @schmidt-sebastian on the latest issue:
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.
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.
The text was updated successfully, but these errors were encountered:
Thanks a lot for your suggestions!
Overall, I agree with you that the SDK has a wrong assumption of how reliable IndexedDB is across all browsers, and there is definitely some improvements to be made!
Thanks for the reply, @wu-hui.
I don't think there has been any doubt about the issues regarding the SDK's assumptions around IDB transactions for at least a couple of months now.
I understand that you might not have the freedom to share the team's roadmap and provide us with an estimate on when this might be accomplished. But I really believe that the Firebase team should consider being more open with their "internal discussions" on an open source project.
There may not be any contractual obligations from Firebase to fix any issues, but we are paying customers. I don't use Firebase for fun; it is part of my job. In turn, I have paying customers being affected by the reliability of our applications.
Like I said in my first post, issues that cause permanent data-loss from a data store product are unacceptable, especially from one no longer in beta. These are not just "improvements". Currently, there are is no way for a developer to completely mitigate this flaw aside from completely disabling, what I would consider, a core feature of the SDK.
It is a little frustrating to hear "I cannot tell when this will be worked on" even when trying to identify ways we might allow for developers to handle these errors. Not to mention the fact that we don't have an estimate on a fix for the original issue or any visibility on if the work is being done. As far as I can tell, there hasn't even been an acknowledgment from the team regarding the severity of the issue.
@wu-hui I wanted to follow up on this again.
I already mentioned this, but there is currently no way, save for turning off the feature entirely (not an option for everyone), for a developer to completely mitigate data loss from this failure. It's a big problem for our organization, and I'm sure it is a problem for more users. Unfortunately, closed issues don't get much traffic.
If you cannot share the roadmap for this fix, then please at the very least confirm that it is being worked on. My concern here is that this problem is being seen as an "improvement" rather than a critical flaw by the Firebase team.
In the case that the fix will take a long time to complete, we need to have tools provided by the SDK to recover from these errors. Reloading the page to re-establish the connection is an unacceptable solution and can easily cause data loss.
I am re-opening the issue to allow tracking of progress for our IndexedDB recovery, which addresses one of the concerns raised in the Issue disruption. I will close this issue again when we have code in place that handles all IndexedDB failure scenarios. So far, the PRs that have been opened are:
The only user-visible change from these PRs is that