-
Notifications
You must be signed in to change notification settings - Fork 66
Client should emit errors rather than logging #55
Comments
Hi Mike, thanks for the report. This sounds like a candidate for something we may want for the next major version release. I will discuss with the team. In the meantime, can I get a 👍 👎 from everyone with respect to how you want to consume errors? |
Related PR that addresses the log spam: #59 How about we do this?
|
I like the idea. It will not break existing implementation and e.g. in our case will allow us to improve the handling. Removing the need to duplicate timeout watching on our end. |
Hi @mbrevoort and @kaspiCZ , Thanks for your feedback and sorry for the delay. We'll get to this very shortly. Best, |
@dlau emit if handler, log if not sounds perfect to me. The goal should be to never trap errors but give client consumer control of how to handle them. |
Is there any progress? |
Hi @MartinNuc , Apologies for the delay, and thanks for inquiring! We're actively working on this. I will update this issue as soon as we release this change. Thank you for your patience, |
We made a fork and using our fixed version for now. This caused an outage of our app because server was waiting for LD to finish which failed to connect to LD API but did not emitted any error. Therefore although the connection was closed already our server thought that its still pending. |
Sorry about that @MartinNuc. The fact that you had to fork to fix it is definitely not what we’re aiming for. We know that installing a 3rd-party library SDK into your own codebase requires a lot of trust, and we take this very seriously. A couple of snags came up in our testing, but we're getting closer to release. Thank you again for your patience, |
Hi @mbrevoort and @MartinNuc, I wanted to let you know we finally released version 3.1.0 in which the client now emits errors instead of logging them if and only if an Let me know if you have any questions or feedback. Best, |
Closing this for now -- please re-open if something comes up. Thanks! |
fix bad parameter that caused a redis query for "launchdarkly:undefined"
When there are errors the client is spamming my logs with multiline stack trace logs like this:
This is a problem is you are using a structured logger, for example a JSON line delimited format. Instead should
emit
errors instead. This would be trivial since the LD client is already anEventEmitter
.This would allow the consumer to control how logs are output. For example:
The text was updated successfully, but these errors were encountered: