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.
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.
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/
The difference between SP- and IdP-Initiated SSO?
LaunchDarkly supports only IdP-initiated SSO:
Identity Provider Initiated (IdP-initiated) SSO. With this option, your end users must log into your Identity Provider's SSO page (e.g., Okta, OneLogin, or Microsoft Azure AD) and then click an icon to log into and open LaunchDarkly the web application.
Service Provider Initiated (SP-initiated) SSO. LaunchDarkly does not support this option: This option gives your end users the ability to sign into the apps Login page and then sends an authorization request to the Identify Provider (e.g., Okta, OneLogin, or Microsoft Azure AD). Once the IdP authenticates the user's identify, the user is logged into app.
MFA Verification Failed. Code is Invalid
You may see an error indicating your MFA code is invalid. This error is caused when the 6 digit code generated by your authenticator app has expired or is tied to the wrong QR code.
If you're trying to set up MFA for the first time, or re-enable MFA after a reset, one possibility is that you're using a 6 digit code from your authenticator app that is tied to a different QR code than the one displayed on the current page. If you're setting up MFA by scanning a new QR code, be sure not to refresh the page before entering your 6 digit code, or a new QR code will be generated, rendering the code on your applicator obsolete. If you're signing up for a new account, or setting up MFA for the first time, we recommend taking the following steps to ensure you're working with the correct QR code:
1. Delete all existing LaunchDarkly QR codes in your authenticator app.
2. Follow the invitation link from your email and scan the QR code displayed.
3. Immediately enter the 6 digit code generated from your application without refreshing.
If you have confirmed that your 6 digit code is being generated for the correct application, or you have already successfully enabled MFA and you are seeing this error, this may be caused by the clock on your authenticator app being out of sync. We recommend the Google Authenticator app, and Google recommends the following steps to verify that you have the correct time on your authenticator app:
- Go to the main menu on the Google Authenticator app
- Tap More Settings.
- Tap Time correction for codes
- Tap Sync now
If you're still experiencing any issues, please contact email@example.com.
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 debugger to verify that the users data is being sent to LaunchDarkly. If you open the debugger in an active tab and call variations on your users, you will see them appear in the debugger 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.
You can read more about the debugger in our documentation here.
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 causesAny 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.
Rules targeting users by attribute are not working
Everything works as expected when you target users individually, and users appear to be receiving the correct variation based on the default rule. So why aren't your rules targeting users by attribute working as expected?
The SDK will only evaluate flags using the user object you provide it. The SDK does not use the attributes shown on the dashboard, and user attributes are not synchronized across SDK instances. The only information that is synchronized is flag configuration related data. You will need to provide all applicable user attributes for your configured targeting rules to apply.
Java SDK: How do I use the SDK behind a HTTP/HTTPS proxy?
The following example shows how to configure your SDK to connect to LaunchDarkly through a HTTP/HTTPS proxy.
LDConfig config = new LDConfig.Builder() .proxyHost("https://PROXYURL") .proxyPort(8080) .proxyUsername("USERNAME") // OPTIONAL .proxyPassword("PASSWORD") // OPTIONAL
.build(); LDClient ldClient = new LDClient("YOUR_SDK_KEY", config);
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 using Postgres to cache feature flag configurations?
Not currently, though we have a store abstraction that you can extend with your own storage backend like Postgres. You can read more about what caches we support here: https://docs.launchdarkly.com/docs/using-a-persistent-feature-store
I am getting a JSON parsing exception with the Java client
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:
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:
How do the mobile SDKs handle airplane/flight mode?
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
userDidUpdatedelegate 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.