Ruby-SDK giving incorrect results

[abhimehta]

#I have been getting different results when using the Ruby SDK.

System Info:
ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-darwin17]
Mac OS Sierra

java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)

I have a user with key: tenant3 that was in variation = true.
I moved the user to be in variation = false for a feature-flag called "false"

However, I occasionally see true.

class LaunchDarklyTest

  def initialize
  end

  def testFlag
    user = {
      :key => "tenant3",
    }

    while true  do
      ld_client = LaunchDarkly::LDClient.new("sdk-afc32799-580f-4a97-9db7-24e6742b01c6")
      puts ld_client.variation("test", user, false)
    end
  end
end

LaunchDarklyTest.new.testFlag

Expected Result:

$ ruby ld.rb
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
true
false
false
true
false
false
true
false
true
true

Could you please help me understand if I am doing anything incorrectly or if this is an issue with ruby-sdk??

Doing the same thing using Java-SDK gives me accurate result

import com.launchdarkly.client.*;

public class LaunchDarkly {
    public static void main(String[] args) {
        LDClient ldClient = new LDClient("sdk-afc32799-580f-4a97-9db7-24e6742b01c6");
        LDUser user = new LDUser("tenant3");

        while (true) {
            boolean showFeature = ldClient.boolVariation("test", user, false);
            if (showFeature) {
                System.out.println("true");
            } else {
                System.out.println("false");
            }
        }

    }
}

[abhimehta]

Found the issue.
It was with my code. I was initializing a client within the loop.

[eli-darkly]

Yes, best practice is to create a single client instance at the top and reuse it, as you were doing in Java.

As for why the original code would produce the results you saw: creating a lot of different client instances would mean making a lot of different streaming connections, and theoretically each of those could go to a different network endpoint due to load-balancing... and some of those might be slightly slower in receiving updates from LaunchDarkly than others. But I would only expect a very brief lag, not the longer inconsistency you saw. I was able to reproduce your output yesterday, but I can't today, so I wonder if there was a transient network issue causing longer lags.