Recovering from IndexedDBTransactionError

[nVitius]

@schmidt-sebastian I wanted to ask a couple of questions about the fix (#2938) that you implemented for the Offline IDB issues that we have been seeing.

First off, thank you for your work on this issue. I know that it hasn't been a simple one to address.

If I remember correctly, the error that IDB would throw on these errors was something along the lines of "transaction can not be completed, database connection already closed".

Looking at the code, it doesn't seem that there is actually anything implemented yet to try to re-open the IDB connection once it becomes available again ref

Are we still expected to refresh the page when these errors occur? If so, are there plans to add code to re-establish the connection?

Either way, the fact that we can finally catch the error is a definitely something we can work with.

P.D. I think it would be a good idea to reference this issue in the Firebase documentation. https://firebase.google.com/docs/firestore/manage-data/enable-offline

For users unaware of the issue, it would result in data loss for their applications.

[google-oss-bot]

I found a few problems with this issue:

• I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
• This issue does not seem to follow the issue template. Make sure you provide all the required information.

[mesqueeb]

I was wondering the same thing

[schmidt-sebastian]

@nVitius / @mesqueeb We are mostly trying to retry on the users behalf. We will do this for all IndexedDB errors that are not result of direct user input - e.g. periodic events, network traffic, syncs from multi-tab. For the two event sources that are under the users control (new writes and new onSnapshot() listeners), we will bubble up the IndexedDB error. This allows our SDK to provide the same guarantees as before without blocking our internal queue. It also gives the user the opportunity to minimize these kinds of errors, e.g. to not issue new writes to Firestore when the app is in the background.

For now, and until #2755 is closed, there will still be IndexedDB errors that crash the AsyncQueue. I am working on addressing all remaining areas. When #2755 is closed, you will no longer need to reload but you might need to re-issue writes and re-register listeners that failed with IndexedDB errors (this change is coming in #2944).

I will file a bug to update the documentation. Thanks for pointing that out.

[schmidt-sebastian]

Filed b/155351358

[nVitius]

@schmidt-sebastian Thanks for the reply. Just wanted to point out that the issue you mentioned, #2755 has been closed for several weeks now. What is the best way for us to continue to track the progress of this as more relevant PRs are merged in?

[schmidt-sebastian]

@nVitius Thanks for raising this. While #2755 asks for some features that won't be fully addressed even with IndexedDB retries are implemented across all operations, I will re-open it and repurpose it for the use case we are addressing right now. I hope that this will help you monitor our progress.