- From: Abhishek Shanthkumar <notifications@github.com>
- Date: Tue, 15 Oct 2024 06:52:36 -0700
- To: w3c/IndexedDB <IndexedDB@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/IndexedDB/issues/431@github.com>
IndexedDB data stored on disk may get corrupted or partially lost due to several reasons including user action. Attempts by the site to read such data fail persistently, and these failures are surfaced differently by each browser. Issue #423 specified the `DOMException` type for one such scenario, but this has an impact only if developers update their sites to handle this specific error appropriately. Can we do more to ensure that the "right thing" happens in these scenarios? We should note that: * Sites may store relational data across object stores and/or databases. * Sites may even store metadata about IndexedDB data in other storage such as LocalStorage. * The impact of and recoverability potential from partial data corruption/loss varies across sites based on the nature of data stored. Considering the above, it is best left to the individual sites to handle these scenarios as suits their specific usage patterns. Discussions and efforts have been ongoing to surface sufficiently detailed errors to the sites so that they are equipped to handle them appropriately (#423, [whatwg #75](https://github.com/whatwg/storage/issues/75)). However, a majority of sites may not handle these errors at all, in which case reads of the affected data will persistently fail. In such cases, when we have a signal that the site does not handle these errors, should we go ahead and delete the entire site data so that the error stops occuring? -- Reply to this email directly or view it on GitHub: https://github.com/w3c/IndexedDB/issues/431 You are receiving this because you are subscribed to this thread. Message ID: <w3c/IndexedDB/issues/431@github.com>
Received on Tuesday, 15 October 2024 13:52:40 UTC