Storage consistency checks fail

[turt2live]

2020-02-18T08:47:43.640Z I StorageManager: Checking storage consistency
2020-02-18T08:47:43.640Z I StorageManager: Local storage supported? true
2020-02-18T08:47:43.641Z I StorageManager: IndexedDB supported? true
2020-02-18T08:47:43.641Z I StorageManager: Local storage contains data? true
2020-02-18T08:47:43.642Z I StorageManager: Crypto initialised? true
2020-02-18T08:47:43.776Z I StorageManager: Sync store using IndexedDB contains data? false
2020-02-18T08:47:43.952Z I StorageManager: Crypto store using IndexedDB contains data? false
2020-02-18T08:47:43.953Z E StorageManager: Data exists in local storage and crypto is marked as initialised  but no data found in crypto store. IndexedDB storage has likely been evicted by the browser!
2020-02-18T08:47:43.955Z E StorageManager: Storage consistency checks failed

[turt2live]

apparently this might be Android despite the thing saying Safari. Just going to blanket this as "mobile browsers"

[turt2live]

Also ChromeOS apparently.

[ara4n]

just saw this first hand in https://github.com/matrix-org/riot-web-rageshakes/issues/2420 on chromeos

[bwindels]

I guess that mobile chrome has different heuristics to decide whether to allow persistent storage or not. In all case rageshakes there was no persistent storage.

[bwindels]

I can imagine it would be more generous in allowing persistent storage if installed as a PWA fwiw.

[bwindels]

Well, maybe not even different heuristics, from https://developers.google.com/web/updates/2016/06/persistent-storage:

Beginning with Chrome 55, Chrome will automatically grant the persistence permission if any of the following are true:

The site is bookmarked (and the user has 5 or less bookmarks)
The site has high site engagement
The site has been added to home screen
The site has push notifications enabled

The permission is automatically denied in all other cases. The goal is to ensure that users can rely on their favorite web apps and not find they have suddenly been cleared.

[t3chguy]

This also includes electron (Linux & Windows) at least

[jryans]

I'm really quite puzzled about what's going wrong here... Potential suspects include:

• the IndexedDB existence check might have bug causing it report no data present when actually there was some
• there could be a race where we place some data in IndexedDB but it hasn't flushed to disk (though Blink claims they flush to disk by default), we then mark in local storage that crypto store is initialised which does persist, and the app is reloaded: next time we'd only have local storage and not IDB data

So far, it feels like we either need to find and fix any bugs in the above, or else stop using local storage and move exclusively to one storage technology (IDB), so we can get out of this hairy world where half the data vanishes.

[turt2live]

One possible reason for this is a rogue riot process holding a lock on the storage, leading to the new process unable to acquire a lock. This happened to me and resulted in me having to force-kill the rogue process for it to recognize my indexeddb

[jryans]

Hmm, interesting... I suppose we could add a startup check to see if any other processes are already running...?

[t3chguy]

#10186 has a lot of logs about this

[samuel-lucas6]

Still getting 'Missing session data' errors in v1.7.14 on Ubuntu. I have had the error on multiple operating systems.

[phaitonican]

Also getting Missing Data on a fresh Arch install... tried deleting ~/.config/element etc still same error, which is strange because few days ago it worked

[turt2live]

I believe this is element-hq/element-desktop#819