-
Notifications
You must be signed in to change notification settings - Fork 125
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
TypeError: value.getLowBits is not a function #203
Comments
It looks like the core issue here may be in the bson library, imported via mongodb. |
@wbt, thanks for your prompt reply As I proposed in the original post, It would be nice to, maybe (it's just an idea) have an "onError" option, or "onUnhandledError", you pick the name, which could be a callback provided by the user, and, on any error that may occur with the uderlying mongodb connection, invoke this callback provided by the user, and let the user decide what to do with this broken/failed log... and, if no callback is provided, then: do nothing, but at least catch the error, and don't let the application crash. |
@erodriguezds Emitting an event seems sensible, but I think a crash in the no-listener case is reasonable because we don't want folks thinking their logs are working just fine only to find out after it really matters that they weren't. |
@wbt , I'm glad you guys find the error handler sensible... hope you can work on this as a "feature request". Regarding the crash in a no-error-handler case, I think it's quite arguable... keep in mind that this library is just a logging "transport"... the user may use other transports as well... and this is actually our case. We also use a Slack-webhook transport to receive critical messages.... so, imagine the slack service is down.. do you think the slack transport should crash my app because there's a problem with Slack? My other transports are still working! |
I don't currently use the MongoDB transport at all, so I'm not going to be working on that anytime soon, and I'm not even the best choice of person for reviewing/testing a proposal from someone else (here's to hoping another maintainer might raise their hand to take that review on!). Winston currently has zero budget for maintainers and PRs for both bugfixes and new features come from the community. In the no-error-handler case, I think your arrangement with multiple handlers is not the norm, but it does seem reasonable to limit the app-crash outcome to a situation where all transports (or all transports above a certain log level) have errored out. |
Ocasionally, I get this error from the logger, which crashes my app:
We log thousand of records every minute... and I can't still find the message that triggers this error.
It would be nice to, at least, catch this error, and not crash the entire application... or maybe to have an option to control what to do whenever this type of errors occurs (maybe an "onUnhandledError" option?).
I think that, as this is simply a logging library/transport-driver, It cannot interfere, in any way, with the app's main flow, so, any error with the underlying MongoDB connection, should be handled properly... or at least: catched.
The text was updated successfully, but these errors were encountered: