launchdarkly / android-client-sdk

LaunchDarkly Client-side SDK for Android
Other
45 stars 23 forks source link

LD SDK doesn't set properly Timber TAG #173

Closed audkar closed 2 years ago

audkar commented 2 years ago

Is this a support request? No. This is bug in Android SDK

Describe the bug Timber TAG is not set on each logged event. current code

Timber.tag(<...>) method must be called before each logged event:

fun LOG(): Tree { 
  return Timber.tag(TIMBER_TAG);
}

To reproduce Observe Logcat with when LD SDK is printing logs. It contains TAGs of Class names where logging happens (instead of LaunchDarklySdk)

I/LDClient: Unknown feature flag "login-card"; returning default value
I/StreamUpdateProcessor: Started LaunchDarkly EventStream
I/StreamUpdateProcessor: Started LaunchDarkly EventStream
I/StreamUpdateProcessor: Started LaunchDarkly EventStream

Expected behavior LaunchDarklySdk tag is used for all events

e.g.

I/LaunchDarklySdk: Unknown feature flag "login-card"; returning default value
I/LaunchDarklySdk: Started LaunchDarkly EventStream
I/LaunchDarklySdk: Started LaunchDarkly EventStream
I/LaunchDarklySdk: Started LaunchDarkly EventStream

SDK version 3.1.5

louis-launchdarkly commented 2 years ago

Hello @audkar, thank you for reaching out. For a separate issue https://github.com/launchdarkly/android-client-sdk/issues/147, we are in the process of looking to potentially replace Timber with a new logging API.

We think having the tag on all log lines will help to filter the logs. Are there any other use cases you have in mind? We want to make sure that if we have a new logging API, that will fit your use case.

audkar commented 2 years ago

We think having the tag on all log lines will help to filter the logs.

Yes. Would it be possible if this easy, a few minutes fix, be done ASAP? (LOG constant be mass replaced with LOG()). And bug fix release is made? Please 🙏 Thinking takes years when a fix is a matter of minutes.

Are there any other use cases you have in mind? We want to make sure that if we have a new logging API, that will fit your use case.

One day it would be good to have logs of LD for critical problems. E.g. LD failed to fetch new values. But that WARN should be printed once, after a few attempts (one round of retries with backoff) has failed. Not spam on every request and every environment.

So for us an existing Timber usage is fine. Just amount of INFO, WARN, ERROR log should be reduced 100x. Majority of current logged events should be VERBOSE or DEBUG level. All of them should be tagged with yours' predefined tags of course 😄

louis-launchdarkly commented 2 years ago

Hello @audkar, thank you for the response - in terms of the timing, we are still working through some ANR fixes so it maybe not be as quick as you would hope, but we will look into this logging behavior after we stabilized the Android SDK.

In the planned logging changes that are in the pipeline, there will be a way to control the Android SDK logs independently so you can silence most of the LD logs.

aengelberg commented 2 years ago

Thank you for fixing this issue. The fix is now released in version 3.1.7.