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

Just enumerating some of the considerations here...

* We have an existing, non-standard means of reporting data loss on upgrade (e.g. when the database was corrupted and needed to be reset). That's not relevant here, but it's worth looking at to see what we did (an enum/message pair, just like exceptions) and what is problematic about it (delivered on the next open by any code in the origin)

* Does this information need to be associated with an origin, database, or even more finely scoped? For example, an origin could have two services A and B, which use separate databases ('db-a', 'db-b'). If A does a write-only/commit tx on freeze/unload which fails, does B get a notification when it opens 'db-b' ? That seems less than ideal. This almost hints at wanting to store a per-database transaction history of some sort.

* Transactions can fail to commit for a fixed number of reasons:
   * Abort due to bad requests, e.g. trying to `add()` the same key twice, or `put()` with the same index key with a uniqueness constraint.
   * Explicit abort() call from script
   * Uncaught exception in request's success/error handler
   * I/O error (actual failure to write to disk, e.g. disk detached, or other OS/hardware failure)
   * Quota exceeded
   * User agent crash
* In all cases, if script is still running, an AbortError with details would be fired at the transaction with details. (Obviously in the UA crash case, script is _not_ still running!)

...

* To flesh out the scenario developers are concerned about:
 * The page allows input of data by the user (e.g. issue comments, mail draft, document edits, etc) 
 * The data is usually stored in browser memory and bidirectionally syncs with a server, but is also persisted to the local database on a regular basis for offline use
 * A freeze event comes in - the document attempts to commit memory state to the database
 * The commit fails for some reason
 * 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.

Other requirements/scenarios/constraints?


-- 
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-385032189