-
-
Notifications
You must be signed in to change notification settings - Fork 266
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
If opening a database fails, promises returned by open
and deferred operations are not rejected
#710
Comments
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 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:
|
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). |
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 |
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 theopen
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.
The text was updated successfully, but these errors were encountered: