Re: [w3c/IndexedDB] How should commit() failures be surfaced when freezing / unloading (#237)

Yes, these are both cases that developers should care about.

> page is getting unloaded, an IDB commit is made, but the commit fails for some reason. The next time the page is loaded -- should this information be conveyed to the app somehow?

If the information is not conveyed then it'll require apps to perform sync logic on every page load. Even if commit failures are rare, the fact that they *can* happen means developers will have to account for them, and without any signals from the browser they'll have to manually check for inconsistencies.

> The page restores - it still has state in memory, and believes it has persisted it to the database, but it is wrong. Ideally, it has some way to know it should persist the data.

This is a really tricky case. The more I think about it, the more I think we should try to run success/complete/error handlers after a resume (if possible). If we don't, I can see lots of issue popping up.

For example, consider some code that wraps an IDB transaction in a promise. If the promise code is persisted across a freeze but the IDB callbacks are dropped, that promise will never resolve or reject.

@spanicker do you know what currently happens to other async callbacks (timers, promises, etc) in the resume case?

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