Launch Darkly Metrics conflating Version numbers.

[matthalbersma]

We've been seeing an abnormal amount of Java SDK versions show up in our metrics for connecting to Launch Darkly.

This is just a small example. It would appear that the metrics is picking up our app versioning and tying that to the SDK version as the JavaClient version.

I would assume that the information is coming from a header, possibly here

I'm wondering if something in our Gradle is resetting the version reporting.

we --> being Smartthings

[eli-darkly]

Even if the Java SDK wanted to put your application version in a header, it has no way by itself of knowing what that version is. I can only imagine that you are providing it somehow. The version string it puts in the User-Agent header by default, in that same piece of logic that you linked to above, is baked into the SDK (it comes from a constant in the source code which we update when we do an SDK release)— it is not inspecting jars in your classpath or anything like that.

Are you doing anything in your configuration to explicitly tell the SDK to use custom header values (like, with HttpConfigurationBuilder methods? Or, do you have any kind of proxy/gateway that might be rewriting HTTP headers?

[matthalbersma]

It would appear that many of our services are still on older releases. I believe the logic for versioning was a little more naive then.

java-server-sdk/src/main/java/com/launchdarkly/client/LDClient.java

Line 427 in 388deab

private static String getClientVersion() {

It appears that it's pulling the version off our our apps manifest. This was for v4.9.1.

Our app manifest looks something like.
Manifest-Version=1.0 Implementation-Version=0.1.0-dev.3221.uncommitted+c86a911 Built-Status=integration

[eli-darkly]

Yes, and the possibility of something like that happening is why we stopped doing it that way. The change was described in the changelog for the 5.0.0 release as "LDClient.version() previously could not be used if the SDK classes were not packaged in their original jar. It now works correctly regardless of deployment details." The version string in the User-Agent header is provided by the same logic.

Unfortunately I don't think it's likely that there will be a patch for this in a 4.x version. Version 4.9.1 is more than two years old, and even the last minor version 4.14.x is already out of support per our end of life policy.