Failed to execute 'abort' on 'IDBTransaction': The transaction has finished.

[sengoontoh]

I am getting these errors out in the field on Android devices running the JS SDK in an Ionic environment. Looks like it happens as soon as the app is resumed (hot start).
The first error I see is:
Failed to execute 'abort' on 'IDBTransaction': The transaction has finished.

Then I see successive:
FIRESTORE (5.8.0) INTERNAL ASSERTION FAILED: AsyncQueue is already failed: The transaction was ..

and every single data operation is not working. It happens both with multi-tab and without multi-tab synchro turned on.

It's quite frustrating to our users as the app is basically non-operational at that point.

• Operating System version: Android 8.0
• Browser version: Webview in Ionic
• Firebase SDK version: 5.8.0 and 5.8.1
• Firebase Product: firestore

[mikelehen]

Offhand I'm not sure what would cause this. Any chance these users are low on disk space? We've had some issues in the past with that.

[sengoontoh]

One bit of info (thank you crashlytics). Things seemed fine in 5.7.0 until I upgraded to 5.8.0.
I'm not seeing any QuotaExceededErrors in the logs so I don't think it's correlated to lack of disk space.

Could this fix in 5.8.0 have introduced the issue: Fixed a crash that could happen when the app is shut down after a write has been sent to the server but before it has been received on a listener.

[sengoontoh]

I rolled back to 5.5.4 and I'm still seeing this issue where I'm seeing Failed to execute 'abort' on 'IDBTransaction' on app resume and everything goes down after that.

[sengoontoh]

Another thing I noticed: it seems to happen as follows:

1. User saves data to firestore
2. User immediately leaves app (backgrounded - not closed)
3. User opens up app a few hours later
4. Bam: Failed to execute 'abort' on 'IDBTransaction'

Help anyone?

[mikelehen]

Are you able to reproduce this yourself? Any chance you could enable logging (firebase.firestore.setLogLevel('debug')) and provide the output?

If you can get a callstack for the "Failed to execute 'abort' on 'IDBTransaction'" error, that might also help.

I'm trying to figure out what might be going on, but the more data we have the better.

[sengoontoh]

@mikelehen I've managed to capture a stack:

Error: Failed to execute 'abort' on 'IDBTransaction': The transaction has finished.
at t.abort (file:///android_asset/www/build/vendor.js:1:1435982)
at file:///android_asset/www/build/vendor.js:1:1434491
at file:///android_asset/www/build/vendor.js:1:1432187
at t.wrapUserFunction (file:///android_asset/www/build/vendor.js:1:1431921)
at t.wrapFailure (file:///android_asset/www/build/vendor.js:1:1432152)
at t.r.catchCallback (file:///android_asset/www/build/vendor.js:1:1431747)
at file:///android_asset/www/build/vendor.js:1:1431314
at file:///android_asset/www/build/vendor.js:1:1432187
at t.wrapUserFunction (file:///android_asset/www/build/vendor.js:1:1431921)
at t.wrapFailure (file:///android_asset/www/build/vendor.js:1:1432152)

And here's the stack for the subsequent AsynQueue errors

Error: FIRESTORE (5.8.1) INTERNAL ASSERTION FAILED: AsyncQueue is already failed: The transaction was aborted, so the request cannot be fulfilled.
at u (file:///android_asset/www/build/vendor.js:1:1324357)
at t.verifyNotFailed (file:///android_asset/www/build/vendor.js:1:1427831)
at t.enqueue (file:///android_asset/www/build/vendor.js:1:1427023)
at t.enqueueAndForget (file:///android_asset/www/build/vendor.js:1:1426963)
at t.handleDelayElapsed (file:///android_asset/www/build/vendor.js:1:1426501)
at file:///android_asset/www/build/vendor.js:1:1426181
at t.invokeTask (file:///android_asset/www/build/polyfills.js:3:15660)
at Object.onInvokeTask (file:///android_asset/www/build/vendor.js:1:76569)
at t.invokeTask (file:///android_asset/www/build/polyfills.js:3:15581)
at r.runTask (file:///android_asset/www/build/polyfills.js:3:10834)

[mikelehen]

@sengoontoh Thanks. I'm afraid that isn't shedding any light on the matter for me. I think a log might help though.

The only place we call abort() is here and as you can see we log a message immediately beforehand. So if we can get that log message it might tell us something useful.

[sengoontoh]

@mikelehen it's slightly difficult for me to run the debug log as I have not been able to reproduce it on my side. I'm only observing it in the field and also unfortunately (or fortunately?) not on all devices. It also happens after a user has the app running for a few hours and resumes the app.

My gut feeling on what's happening is the FS JS SDK is in the process of doing a .set() before the app is closed, IDDB successfully does the write transaction but the process ends up getting backgrounded by the OS before being acknowledged by the FS driver layer so when it wakes up, it starts executing the "catch" handler of the .set operation. Hence the wrapUserFunction in the stack. Note that my catch code does not do an abort so it must be part of the wrapper of the user function.

Any thoughts?

[mikelehen]

@sengoontoh I'm not very familiar with ionic. Do you know more specifically what is happening when the app is "backgrounded" and when it "wakes up"? On wake up, does the app reload from scratch (i.e. like a page refresh in a browser)? Or is it just resuming execution without starting over?

If the latter, then I fear this may be an ionic-specific issue of some kind... where it's closing our IndexedDb transaction in the middle of our processing or something. We have a slightly similar report on Chrome in #939 but the symptoms aren't the same.

[sengoontoh]

@mikelehen
ionic uses WebKit to render a website in an app frame. I tried pausing my debugger console but couldn't replicate the issue.

[sengoontoh]

Would it be possible for the catch fail code to ignore this "Error: Failed to execute 'abort' on 'IDBTransaction': The transaction has finished." error and not mess up the AsynQueue so as to recover gracefully?

[mikelehen]

@sengoontoh Unfortunately not. If one of our transactions fails, that leaves the SDK in an unknown state and continuing to let the SDK run could lead to corruption of the offline cache (since something we think we wrote was not actually written).

Ideally we would figure out what is causing the failure and avoid it.

Failing that, we could take a look at hardening all of our transactions to be resilient to failures (retry or otherwise fail gracefully), but this is a large undertaking and is inherently risky since we wouldn't be able to test these codepaths without knowing how they're being triggered.

So we really need a way to reproduce this or more details on how the error is coming about. Sorry. 😦

[google-oss-bot]

Hey @sengoontoh. We need more information to resolve this issue but there hasn't been an update in 7 days. I'm marking the issue as stale and if there are no new updates in the next 3 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[google-oss-bot]

Since there haven't been any recent updates here, I am going to close this issue.

@sengoontoh if you're still experiencing this problem and want to continue the discussion just leave a comment here and we are happy to re-open this.