Receiving several WebKit related IndexedDB errors

[Helveg]

Hi!

I've read through the docs, and saw that several errors are to be expected when dealing with WebKit and IDB. I'm receiving several error reports through telemetry for users of Safari/iOS all related to either the DB connection closing, the user requesting to delete the DB, the DB being corrupted.

My question is: Is there a way to tell this library to fall back to another storage mechanism than IDB? Or, can it retry, or fall back when these errors occur?

PS: Where is the source code? O_O

[cyrilletuzi]

Hello,

Is there a way to tell this library to fall back to another storage mechanism than IDB? Or, can it retry, or fall back when these errors occur?

There is already such a mechanism at the initialization of the service. But it is not possible to fallback later on, because data would be completely inconsistent. Imagine this scenario:

• the service initializes with indexedDb because there is no error when opening the database and it is supposed to work
• a first key/value is successfully stored (to indexedDb)
• another operation fails and the service fallback to localStorage
• now you try to access the first key, which will be looked into localStorage where it does not exist because it is in indexedDb

I would need more elements to investigate:

• what are the errors exactly?
• could you provide a reproduction?
• what version of Safari are you using (because some Safari versions are known to have indexedDb issues)?

[Helveg]

A reproducer is impossible because I'm merely receiving these errors through telemetry from our deployed application. (And they don't occur when I simply open and remote debug the website on my iPad).

Can I configure this initialization mechanism somehow? Because of WebKit's poor track record with IDB I'd prefer to disable it there alltogether

Here are a couple of the error messages (I don't have a full stack trace), I also have the full Rollbar reports, if you are familiar with that provider I can give you those as well:

UnknownError: Attempt to get a record from database without an in-progress transaction

InvalidStateError: Failed to execute 'transaction' on 'IDBDatabase': The database connection is closing

 UnknownError: Database deleted by request of the user

These are some of the reported browser fingerprints:

Mozilla/5.0 (iPhone; CPU iPhone OS 17_1_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/21B101 Instagram 312.0.1.19.124 (iPhone13,1; iOS 17_1_2; nl_BE; nl; scale=3.00; 1125x2436; 548339486) NW/1

Mozilla/5.0 (iPad; CPU OS 17_1_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/21B101 [FBAN/FBIOS;FBAV/445.0.0.35.117;FBBV/548375166;FBDV/iPad12,1;FBMD/iPad;FBSN/iPadOS;FBSV/17.1.2;FBSS/2;FBID/tablet;FBLC/nl_NL;FBOP/5;FBRV/552605239];FBNV/1

Mozilla/5.0 (iPhone; CPU iPhone OS 17_1_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.1.2 Mobile/15E148 Safari/604.1

I checked some more occurences and they're all iOS desktop or mobile devices, they all seem to be running iOS 17, but if I didn't dream this, I swear I saw a 15 somewhere as well :D

The InvalidStateError was reported with a stack trace, with the 2 innermost stack frames being related to your package:

at transaction([native code])

at [anonymous](webpack:///./node_modules/@ngx-pwa/local-storage/fesm2022/ngx-pwa-local-storage.mjs:345:40)
transaction = database.transaction([this.storeName], mode);

[cyrilletuzi]

Thank you for the logs. I will try to investigate. I have seen there was some indexedDb bugs in some betas of iOS 17, but they are supposed to be fixed in final versions.

Can I configure this initialization mechanism somehow? Because of WebKit's poor track record with IDB I'd prefer to disable it there altogether

If completely falling back to localStorage, this library becomes quite useless. You can do it directly with something like that:

if (/* Your Safari detection */) {
 localStorage.setItem();
} else {
  this.storageMap.set();
}

It would not be a good idea to include such an option in the lib for several reasons:

• browser detection is a bad practice, if there is a issue in an browser, either the lib is able to find a workaround, otherwise the browser should be fixed
• it is an option that, if changed during the lifetime of an application, would mean the loss of data for all the users concerned by the exception; I already added such an option and I regret it because the lib is now stucked with it forever, because a migration is not possible, so it needs to still be here to avoid a loss of data in existing applications

[Helveg]

Thanks, if I can help in any way with your future investigations let me know!

I haven't been able to reproduce, but since some of them are about the database closing, it might have to do with the fact that I try to delete local storage items to clear the shopping cart, and then navigate away to a checkout URL of a payment provider.

This happens with a forkJoin(items.map(item => this.storage.delete(item.key))) switchMapped and followed by a subscription that window.open(paymentUrl, '_self')

    this.orderApi
      .placeOrder(campaign, sanitizedOrder, cart, sales)
      .pipe(switchTap(() => this.cartSvc.clearCart(cart)))
      .subscribe(({ paymentUrl }) => {
        window.open(paymentUrl, '_self');
      });

(switchTap is a switchMap that passes on the original value, and clearCart is the forkJoin of deletes that I spoke of)