Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Receiving several WebKit related IndexedDB errors#1001

Answeredbycyrilletuzi
Helveg asked this question inQ&A
Discussion options

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

You must be logged in to vote

Thank you for the logs. I will try to investigate. I have seen there was someindexedDb 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 tolocalStorage, 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 brows…

Replies: 2 comments 2 replies

Comment options

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 withindexedDb because there is no error when opening the database and it is supposed to work
  • a first key/value is successfully stored (toindexedDb)
  • another operation fails and the service fallback tolocalStorage
  • now you try to access the first key, which will be looked intolocalStorage where it does not exist because it is inindexedDb

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 haveindexedDb issues)?
You must be logged in to vote
1 reply
@Helveg
Comment options

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

TheInvalidStateError 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);
Comment options

Thank you for the logs. I will try to investigate. I have seen there was someindexedDb 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 tolocalStorage, 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
You must be logged in to vote
1 reply
@Helveg
Comment options

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 aforkJoin(items.map(item => this.storage.delete(item.key)))switchMapped and followed by a subscription thatwindow.open(paymentUrl, '_self')

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

(switchTap is aswitchMap that passes on the original value, andclearCart is theforkJoin ofdeletes that I spoke of)

Answer selected byHelveg
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
Q&A
Labels
None yet
2 participants
@Helveg@cyrilletuzi
[8]ページ先頭
©2009-2025 Movatter.jp