- From: Abhishek Shanthkumar <notifications@github.com>
- Date: Mon, 23 Sep 2024 05:12:52 -0700
- To: w3c/IndexedDB <IndexedDB@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/IndexedDB/issues/423@github.com>
IndexedDB data stored on the file system can be lost due to factors beyond the browser's control, such as when users directly delete the files containing the data. Total data loss of the `database` or `object store` is visible to the script as an _absence_ of data, and can be appropriately handled by it. However, since the current specification does not mandate consistent data storage, there is a chance of partial data loss where the entry for a `record` exists in the `object store` but the contents of the `record` are lost. For example, both Chromium and Firefox store blobs and large values in files separate from the main database, which only contains references to these files. When those files are deleted, the references in the database become dangling and attempts to read the data fail permanently. The specification does not cover the above scenario, and hence the `DOMException` thrown varies by browser: * Chromium: * `name`: `NotFoundError` ([updated recently](https://chromestatus.com/feature/5140210640486400)) * `message`: "Failed to read large IndexedDB value" * Firefox: * `name`: `UnknownError` * `message`: "The operation failed for reasons unrelated to the database itself and not covered by any other error code." Specifying a common `DOMException` for such cases of partial data loss will help developers handle these scenarios consistently across browsers. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/IndexedDB/issues/423 You are receiving this because you are subscribed to this thread. Message ID: <w3c/IndexedDB/issues/423@github.com>
Received on Monday, 23 September 2024 12:12:56 UTC