Skip to content
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

Open
erodriguezds opened this issue Jun 28, 2022 · 5 comments
Open

TypeError: value.getLowBits is not a function #203

erodriguezds opened this issue Jun 28, 2022 · 5 comments

Comments

@erodriguezds
Copy link

Ocasionally, I get this error from the logger, which crashes my app:

TypeError: value.getLowBits is not a function
    at serializeLong (/usr/src/app/node_modules/bson/lib/bson/parser/serializer.js:388:23)
    at serializeInto (/usr/src/app/node_modules/bson/lib/bson/parser/serializer.js:956:17)
    at serializeObject (/usr/src/app/node_modules/bson/lib/bson/parser/serializer.js:347:18)
    at serializeInto (/usr/src/app/node_modules/bson/lib/bson/parser/serializer.js:941:17)
    at serializeObject (/usr/src/app/node_modules/bson/lib/bson/parser/serializer.js:347:18)
    at serializeInto (/usr/src/app/node_modules/bson/lib/bson/parser/serializer.js:941:17)
    at serializeObject (/usr/src/app/node_modules/bson/lib/bson/parser/serializer.js:347:18)
    at serializeInto (/usr/src/app/node_modules/bson/lib/bson/parser/serializer.js:941:17)
    at serializeObject (/usr/src/app/node_modules/bson/lib/bson/parser/serializer.js:347:18)
    at serializeInto (/usr/src/app/node_modules/bson/lib/bson/parser/serializer.js:941:17)
    at serializeObject (/usr/src/app/node_modules/bson/lib/bson/parser/serializer.js:347:18)
    at serializeInto (/usr/src/app/node_modules/bson/lib/bson/parser/serializer.js:727:17)
    at serializeObject (/usr/src/app/node_modules/bson/lib/bson/parser/serializer.js:347:18)
    at serializeInto (/usr/src/app/node_modules/bson/lib/bson/parser/serializer.js:941:17)
    at BSON.serialize (/usr/src/app/node_modules/bson/lib/bson/bson.js:64:28)
    at Msg.serializeBson (/usr/src/app/node_modules/mongodb/lib/core/connection/msg.js:126:22)
Emitted 'error' event on DerivedLogger instance at:
    at DerivedLogger.transportEvent (/usr/src/app/node_modules/winston/lib/winston/logger.js:630:12)
    at exports.MongoDB.emit (node:events:539:35)
    at /usr/src/app/node_modules/winston-mongodb/lib/winston-mongodb.js:230:12
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

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.

@wbt
Copy link

wbt commented Jun 28, 2022

It looks like the core issue here may be in the bson library, imported via mongodb.
Supposing the error is caught, what do you think should happen in the catch block?

@erodriguezds
Copy link
Author

@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.

@wbt
Copy link

wbt commented Jun 30, 2022

@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.

@erodriguezds
Copy link
Author

@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!

@wbt
Copy link

wbt commented Jul 1, 2022

@wbt , I'm glad you guys find the error handler sensible... hope you can work on this as a "feature request".

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants