Re: [w3c/IndexedDB] Specify the exception for read failures arising due to partial data loss on the file system (Issue #423)

> Thoughts? Should we specify the conditions for throwing a `NotReadableError` in a common place instead of for individual methods?

This seems good, thank you.  I don't have a strong opinion other than, if there aren't many cases of needing the verbiage to throw the error and the verbiage isn't too verbose, having them in-line as opposed to in an extracted algorithm makes it more likely people will see that that can happen?

> > data corruption should result in the containing storage bucket being cleared
> 
> We discussed this briefly for Chromium too. Yes, deleting the storage bucket entirely would leave things in as consistent a state as possible, but it is a destructive action whose impact could vary based on how the website is using IndexedDB. Hence, it seemed better to surface the error clearly to the website so that it could take the right corrective action for its use case. We could discuss this further, though, and also perhaps solicit developer feedback.

Yes, it would be good to discuss this further, and it need not be on this issue.

I agree with the rationale that if a site can take corrective action, it would be good to enable the site to take corrective action.  Unfortunately we've found many users of IDB don't really handle errors, so it would be desirable to have some kind of strong signal that the site is taking responsibility for dealing with the error.  But I suppose that could be as simple as "the default behavior of a NotReadableError is clearing your bucket, so call preventDefault if you think you can clean things up".

A meta issue for us is that right now, for non-Private Browsing Mode (PBM), we really only have SQLite's concept of detecting corruption and structured deserialization errors from JS, so if corruption happens, it's very hard to tell what still might be good.  For PBM we actually use AEAD encryption on a database page level and blob chunk basis so we potentially have a much better idea of what is good and what is bad, and we might potentially move to using AEAD for non-PBM cases to that end in order to be able to better characterize the integrity of data.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/423#issuecomment-2375506223
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/423/2375506223@github.com>