If opening a database fails, promises returned by open and deferred operations are not rejected

[abacabadabacaba]

With levelup, it is possible to use database objects before they are fully open. If a method that needs an open database is called, the call is deferred until the open operation is complete. Also, if the open method is called while the database is being opened, it will wait for the running open operation to complete instead of initiating a new one.

If the open operation fails, a user would expect all the deferred operations to fail as well. However, this is not what happens. Instead, error event is fired (which is not fired for any other errors), and the deferred calls never finish: callbacks are never called, promises are never settled.

I think that if open operation fails, database should enter an error state in which all pending and future calls immediately fail with an error. While in the current code it is possible to attempt to reopen a database after an error, this is rarely what the user wants. In the current code, if a method is called after a failed attempt to open the database, it will be deferred in anticipation that the user will try to open the database again. In asynchronous code, it is easy to call a method after the open operation fails but before the failure is processed by the user code. In this case, if the user code doesn't attempt to reopen the database, these calls will hang.

[vweevers]

While [..] it is possible to attempt to reopen a database [..] this is rarely what the user wants

In addition, reopening will not make a difference. For most stores, failing to open is not a transient error that can be retried, so usually the best course of action is to crash. In Node.js we rely on the built-in error event behavior to achieve that: if there is no listener for that event, it crashes. There's no equivalent behavior in browsers, though the error event does give the user the opportunity to handle a failed open in a single place.

I agree that deferring operations is only useful while the db is opening. Currently we also defer operations after the db was explicitly closed by the user, but I wouldn't mind rejecting new operations in that case - to simplify. Then we can do the following:

• While db.status === 'new': reject operations
• While db.status === 'opening': defer new operations
• On open error: reject deferred operations (note that db.status reverts to 'new')
• While db.status === 'open': allow new operations
• While db.status === 'closing' or db.status === 'closed': reject new operations

[abacabadabacaba]

so usually the best course of action is to crash

It should be up to the application developer what to do if the database cannot be opened. Also, when an operation that returns a promise fails, it is expected that the promise is rejected. The current behavior (when the promise is neither resolved nor rejected) is unexpected and means that promise-based API cannot be used in code that wants to handle errors (even only to display a nice error message to the user instead of an ugly traceback).

[vweevers]

To clarify, I meant "usually the best course of action for the application is to crash". Although we offer that choice (or at least intend to) it's not much of a choice because not crashing means having to stay in an unhealthy state with dangling promises. As for the rest of your answer, I was already in agreement with you 😉

I started exploring this in abstract-level (Level/community#58).

[vweevers]

Done in https://github.com/Level/abstract-level