Re: [w3c/IndexedDB] Delete entire site data on data corruption/loss? (Issue #431)

Quoting https://github.com/w3c/IndexedDB/issues/431#issue-2588856164
> 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)).

I don't really expect that sites can meaningfully do much more than could be done automatically if the site was using multiple storage buckets.  But I do believe there are sites that will want to handle this and it seems reasonable to provide an opt-in affordance.

One thing I should note is that in https://github.com/w3c/IndexedDB/issues/423#issuecomment-2375506223 I proposed that calling preventDefault() on an error reporting corruption could prevent the default behavior of wiping the containing storage bucket because this is a straightforward use of the IDB event model, but this is of course potentially at odd with promise ergonomics because it's easy to go async in a way that depends on a new task being scheduled rather than everything being resolved in the microtask checkpoint for the event dispatch.  I believe there is some related discussion in the proposal of observables in https://github.com/WICG/observable/issues/170 (in particular involving preventDefault()).

If we wanted to ensure promises could go fully async, we'd want something like along the lines of ServiceWorker's FunctionalEvent.waitUntil so that it's still valid to call preventDefault() (and stalling the IDB transaction) until the passed-in promises either all resolve or reject.  Semantically, a rejection there is potentially confusing if one thinks about it too much, but from a spec perspective would map equivalently to an exception being thrown by the event handler.

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

Message ID: <w3c/IndexedDB/issues/431/2417193595@github.com>