Application

  • Why should I avoid individually targeting too many users?

    Individually targeting users increases the size of the payload fetched by the SDK when initializing, and the memory footprint of the SDK.

    A better strategy would be to assign a custom attribute to the users who should receive the feature flag and then set up the targeting rules to serve the flag to users who have that attribute. This allows you to target groups of users without increasing the size of the payload.

    You can read more about our targeting rules here. 

  • How long does it take for users to appear in the dashboard?

    It generally takes just a couple of minutes for a user to appear in the dashboard. 

    You can check the dev console to verify that the users data is being sent to LaunchDarkly. If you open the dev console in an active tab and call variations on your users, you will see them appear in the console almost immediately. This is a great option to make sure that LaunchDarkly is receiving your user data without waiting for users to appear in the dashboard.

  • How can I be notified of interruptions to the LaunchDarkly service?

    The best way to get updates from us regarding service status is by subscribing to this RSS feed: http://status.launchdarkly.com/

  • I am unable to connect because of a mismatched origin header
    We take the security of your data at LaunchDarkly seriously. One of the protections we've implemented is validation that the Origin header for any API request authenticated by session cookie matches the expected Origin header (namely https://app.launchdarkly.com). This is just one way that we help to prevent CSRF attacks. (Note that we do not require origin matching when authenticating via Access Token, so this does not affect normal API usage.)
     
    If the Origin header does not match what's expected, we return an error. And since our application relies heavily on interaction with the API, the application will not function properly.
     
    Known causes
    Any browser extension that intentionally changes the Origin header will cause this problem. For example, the Allow-Control-Allow-Origin: * Chrome extension is known to change the Origin header to http://evil.com and will result in the problems described above.
  • What does "Your configuration is incomplete" mean?

    If you're seeing the "Your configuration is incomplete" message, it will usually indicate that there is an incomplete or invalid rule configured for your flag. For example, this could mean that an attribute was not selected, or a negative number was selected for a percentage rollout.

  • Why are all my users seeing the same variant of my flag?

    Make sure that you’re sending distinct user keys for each user in your variation calls. A few other possibilities:

    • Your default rollout rule is serving a single variation
    • Your users are receiving the fallback variation because something is not working correctly
    • The kill switch was activated, and the feature is set to ‘Off’
See all 9 articles

SDKs

  • JavaScript SDK: Events blocked by DNT or Adblock

    When you evaluate feature flags, the SDK queues up an analytic event to send back to LaunchDarkly. The events endpoint is used to send these events. If you are working with the JavaScript SDK, enabling your browser's Do Not Track setting or using Adblock will block all requests to events.launchdarkly.com. 

    Rest assured that this does not impact your user evaluations - your users will continue to receive the correct variation for the requested flags. This only impacts the ability to send information back to LaunchDarkly.

  • Does the LD SDK support Postgres as a caching backend?

    Not currently, though we have a store abstraction that you can extend with your own storage backend like Postgres.

  • I am getting a JSON parsing exception with the Java client

    Exception:

    Json parsing exception: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was….ExceptionType: com.google.gson.JsonSyntaxException

    Make sure your build tool is bringing in the proper version of Gson. The LaunchDarkly SDK may have problems with versions earlier than 2.2.4. To enforce the proper version add this dependency:

    <dependency>
     <groupId>com.google.code.gson</groupId>
     <artifactId>gson</artifactId>
     <version>2.2.4</version>
    </dependency>

     

  • I am getting SSL exceptions when calling variation() in the Java client

    Make sure your build tool is bringing in the proper version of the Apache http client. The LaunchDarkly SDK may have problems with versions earlier than 3.3.6. To enforce the proper version add this dependency:

    1. <dependency>
    2.  <groupId>org.apache.httpcomponents</groupId>
    3.  <artifactId>httpclient</artifactId>
    4.  <version>4.3.6</version>
    5. </dependency>
  • Every time I call get_flag, a remote call is made.

    One possibility is that you have streaming mode disabled and your feature’s TTL is set to 0. We do not recommend disabling streaming unless you are using PHP. If you do disable streaming mode, we recommend setting the TTL to 5 minutes in production environments.

    If you’re using PHP, you may need to configure a custom HTTP cache provider as described in the PHP SDK Reference. PHP’s shared-nothing architecture means that the in-memory HTTP cache will be reset on every request, which means that almost every flag request will require a remote call. Using a Memcache or Redis-backed cache is the best solution.

     

Mobile

  • How do the mobile SDKs handle airplane/flight mode?

    When a user is in flight or airplane mode on their mobile device, LaunchDarkly will use the latest stored flag settings.  When the user reconnects to a network, LaunchDarkly will reconnect to the stream to see if there are any new flag updates.  This ensures that your users will always receive the most up-to-date flag settings, even if their devices are not currently connected to a network.

     
  • I’m seeing inconsistencies in iOS SDK flag evaluation

    There are a few things to be aware of with the iOS SDK:

    • The iOS SDK utilizes a streaming architecture to keep itself in sync with your configurations on the dashboard. If any change is made, these changes will be picked up by your iOS users the next time they get online.
    • When the SDK receives any updates from LaunchDarkly they are cached to Core Data, so that the SDK can still evaluate flags even when offline.
    • When a user first installs your app, until the first stream is established with LD, the default variation values will be used. There is a delegate pattern (see userDidUpdate) that can be used to block until the first response is received.
    • When a current user uses the app while offline, or if variation calls are made before the SDK has has finished initializing, then the SDK will continue to serve variations using the old state, and you may see these events show up occasionally in your dev console after making changes.
    • If your SDK If you need to change your user, or you want to wait until the SDK has finished synchronizing with LaunchDarkly, you should use the userDidUpdate delegate to wait until the feature flags for the new user have been received.
  • Why is there a different mobile environment SDK key?

    The server SDK keys are intended to be embedded in trusted environments. The mobile SDK keys are suitable for use in (untrusted) mobile clients. If a mobile user were to somehow decompile your app, or gain access to your mobile key, there is really no impact, as those keys can only access a restricted subset of our APIs that do not reveal any private data.