-
Notifications
You must be signed in to change notification settings - Fork 56
Excessive logging for invalid SDK key #238
Comments
Whoops, yes, this is definitely a bug. As you guessed, the code is supposed to treat a 401 as a permanent failure (since an invalid SDK key can never become valid again) and something in that logic is clearly broken now. Which I guess means the test coverage for it is also wrong somehow, since I'm fairly sure we have unit tests specifically for this. Investigating. |
Indeed, we had a test, but it wasn't a valid test. The way we were setting up mock server responses wasn't adequately realistic— we're currently working on implementing better end-to-end tests to catch just this sort of thing. Anyway, sorry about this and it should be a straightforward fix; we're working on it now. |
Version 5.5.1 has been released and should fix this. |
And thanks for bringing it to our attention. |
@eli-darkly We are using launchdarkly-java-server-sdk Should I open a new bug report or am I missing something? |
@frederikvanhoyweghen That looks like it is a different bug— that is, it's the same kind of issue, but it's in a different component that was not what the original bug report was about. If you wouldn't mind filing a separate issue, that'd be helpful. |
Is this a support request?
No
Describe the bug
When an LDClient has a bad SDK key (because it expired or was bad from the beginning), it repeatedly logs about it and triggers any
DataSourceStatusProvider.StatusListener
sTo reproduce
INFO com.launchdarkly.sdk.server.LDClient.DataSource - Initialized LaunchDarkly client.
ERROR com.launchdarkly.sdk.server.LDClient.DataSource - Error in stream connection (giving up permanently): HTTP error 401 (invalid SDK key)
pizza
The same issue exists for
StatusListener
sWe were also considering setting up alerts for sites that have expired SDK keys, and we were considering using the
DataSourceStatusProvider
for that.However, if I add this code into my test:
then you will see that the listener is also repeatedly called:
Upon further inspection, if I make my listener always print what the
State
was:then it seems to oscillate between
INTERRUPTED
andOFF
:Expected behavior
If it really "gives up permanently" (which it should do for an invalid SDK key), then it should only log that message once. 🙂 That also seems to be what this code is trying to do?
Also we kinda expected addStatusListener to only trigger for status changes, which should only be once for a non-recoverable error like having an invalid SDK key.
Logs
SDK version
5.3.0
, but also confirmed the error exists on5.5.0
Language version, developer tools
Java 8, IntelliJ 2021.1.1 Community Edition
OS/platform
MacBook Pro 2019
macOs Catalina
Version 10.15.7
Additional context
This causes us concern since we have a lot of long-running sites that may begin to operate on a stale SDK key if we rotate the SDK key. While this is mostly fine, since the sites will just stop getting updates from LaunchDarkly, the excessive logging could be a problem for our disk space utilization and logging quality.
The text was updated successfully, but these errors were encountered: