fwiw localstorage and the new mojo session storage implementation have the exact same behavior, as it seemed the most reasonable way of dealing with database open errors.

I'm curious how you suggest differentiating between different failure modes? Ultimately "throw away the entire database" is our stop-gap measure to prevent ending up in a situation where localstorage/sessionstorage will never work again because opening fails. Since there isn't anyway in the UI for the user to actually throw away the database (even cleaning all storage won't, since by the time that option reaches the dom storage code it is as a series of "delete this origin" calls) we need some way to deal with corruption.

So what should we be doing instead of throwing away the database? At least if we throw away the database there is a chance things will start working again (with some data loss for previous data). If we don't throw away the database instead you'll lose all changes you make until somehow whatever triggered the open errors is fixed and you sub-sequentially restart chrome? (but you'd still lose everything you did during the session in which the DB failed to open).

mek@, I agree that you raise an excellent question and I'm not quite sure how to solve it. However, at present 0.04% of all sessionStorage db opens fail and after successfully deleting the db, only 13% are able to be opened (created actually). So even after deleting all the user's data in that db it still doesn't buy us much. My guess is that FD's are exhausted, or maybe the db is on a network shared profile (see issue 647385). So 76% of the time (when we fail to open the first time) we just delete, and then fail the retry.

It would be good to come up with a better solution I think.