Android - configure promise always timeout and resolves, but flags are not available in local development

[rgommezz]

Describe the bug

Edit: it works perfectly on release type builds, so the issue only happens when running a local development server.

This is a follow-up on #227, since it was closed and I am not sure if it's getting attention after that.

Dependencies:

"expo": "^49.0.11",
"react-native": "^0.72.5",
"launchdarkly-react-native-client-sdk": "^8.0.1",

Some of my findings based on my configure call are outlined below:

await client.configure(
  {
    mobileKey: launchDarklyKey,
    enableAutoEnvAttributes: false,
  },
  {
    kind: 'user',
    key: 'someId',
    userId: '1'
  },
  Platform.OS === 'android' ? 2 : undefined
);

• If I don't set a random timeout, the promise never resolves
• Skipping enableAutoEnvAttributes also seems to make the promise hung forever
• Interestingly the promise resolves right after the timeout fires. If I set it to 2, it resolves after 2 seconds, if I set to 5, after 5 seconds. However, the flags are never available, and when accessing them, the getters always return the default value set.

For instance, await ldClient.boolVariation('someKey', false) always resolves to false. The documentation states that the configure promise will be rejected.

The picture below represents 2 users with active sessions trying to access feature flags, BooleanTest whose value is true, and StringTest whose value is foo. 1 user is on Android and the other is on iOS. The highlighted part is the result of Android getting values, which always resort to the default value set in code, whereas iOS works as expected.

To reproduce
Create a Expo project on v49 with a development client and prebuild

Expected behavior
Feature flags should be available when accessing them on Android, since the configure call resolves successfully

SDK version
8.0.1

Language version, developer tools
React Native

OS/platform
Android

[greatergoodguy]

Also encountering this issue and I'm baffled as to why it's happening. iOS works perfectly, but Android configure method always times out and I just don't know why.. This was happening on SDK 6.3.3.

I upgraded to SDK 7.1.8 hoping it would fix, but I'm STILL having the same issue.

[andreaSimonePorceddu]

I'm in a similar situation; it is not systematic, but many times, the configuration never resolves, and our app gets stuck in the splash screen because we wait for the flag to be synced before opening the app. It is a critical issue because it prevents many users from opening the app. It starts to do it during last days, so I don't know if it can be related to the android SDK release but we need to have it fixed as soon as possible.

Our configuration is:

"react-native": "0.72.6",
"launchdarkly-react-native-client-sdk": "ˆ8.0.1“

Our method is implemented in this way

const init = () => {
      await featureFlagsClientInstance.configure(configuration, defaultUser);
      hideSplashScreen()
}

Our configuration is:

const configuration: LDConfig = {
  mobileKey: env?.LAUNCH_DARKLY_MOBILE_KEY,
  enableAutoEnvAttributes: true
};

The hideSplashScreen is never called, only for android. I repeat, it affects 50% of our users, and we have 30.000 users right now; please let us know about this issue.

[andreaSimonePorceddu]

ADDITIONAL INFORMATION: It is affecting even old version of the the SDK, so I'm supposing that it could be something that launch-darkly has released recently.

[choudlet]

im also experiencing this issue and cannot serve android builds currently due to being locked behind the splash screen as the launch darkly configure never returns. Are there any fixes coming for this. I'm going to have to remove LD from android builds for the time being.

[andreaSimonePorceddu]

@choudlet

Hi Cloudlet, which version of react-native do you have, I noticed that for us, the problem started when we released a version updating react-native from 0.72.4 to 0.72.6. I'm still waiting for a tester who has this issue systematically to give me feedback with a build I provided with the 0.72.4 version to see if the problem persists with that version.

[tanderson-ld]

@andreaSimonePorceddu , did you ever notice the issue on RN 0.72.4?

[tanderson-ld]

ADDITIONAL INFORMATION: It is affecting even old version of the the SDK, so I'm supposing that it could be something that launch-darkly has released recently.

@andreaSimonePorceddu Do you recall which version of RN this was done with?

[yusinto]

@andreaSimonePorceddu I ran the ManualTestApp to try and reproduce the issue but both the configure and identify functions work correctly for me. Are you able to try and run the said ManualTestApp and see if you can reproduce please?

On a side note, if your init function is awaiting a promise, it should be marked async:

const init = async () => { // should be async
      await featureFlagsClientInstance.configure(configuration, defaultUser);
      hideSplashScreen();
}

[andreaSimonePorceddu]

@andreaSimonePorceddu I ran the ManualTestApp to try and reproduce the issue but both the configure and identify functions work correctly for me. Are you able to try and run the said ManualTestApp and see if you can reproduce please?

On a side note, if your init function is awaiting a promise, it should be marked async:

const init = async () => { // should be async
      await featureFlagsClientInstance.configure(configuration, defaultUser);
      hideSplashScreen();
}

The real one is async:

I just simplified it here. The test app uses react-native 0.71; it is not the same case.

[greatergoodguy]

It will help greatly if LD can fix the bug where configure promise always timeout and yet still resolves. If configure times out, it should fail and give the user a descriptive error message, instead of resolving successfully.

[greatergoodguy]

let config = { 
  mobileKey: AppConfiguration.getLaunchDarklyMobileKey(),
  stream: false, // This fixes the issue
};
let context = { key: `${accountInfo?.customer_details?.username}`, kind: 'user' };
await client.configure(config, context, 5);

In the configuration object, when I set stream to false, my issue was fixed. This changes the connection from streaming to polling

[yusinto]

We don't officially support expo. However, there is a known issue with react native android where Flipper intercepts sse streaming connections causing them to fail. See facebook/flipper#2495. The symptoms described here seem to be pointing to that.

Production android builds don't use Flipper and so don't suffer from this issue.

[andreaSimonePorceddu]

We don't officially support expo. However, there is a known issue with react native android where Flipper intercepts sse streaming connections causing them to fail. See facebook/flipper#2495. The symptoms described here seem to be pointing to that.

Production android builds don't use Flipper and so don't suffer from this issue.

It happens even in production in our case, and we don't use expo.

[louis-launchdarkly]

Hello @andreaSimonePorceddu, your issue seems to be different from the original issue opened as you stated yours are happening outside local development. We recently updated the ManualTestApp to use RN ^0.72.4 (https://github.com/launchdarkly/react-native-client-sdk/blob/8.0.2/ManualTestApp/package.json#L20) - I wonder would that help you in trying to reproduce the issue? Streaming in the ManualTestApp is working when we try to update and release the new version of the SDK.

[joeyhotz]

Hi @louis-launchdarkly, we only started to notice the issue when upgrading to react-native 0.72.6.
Just wondering if anyone has any updates or fixes for this? It's looking like our only option is to disable streaming which appears to resolve the issue for android devices.

[github-actions]

This issue is marked as stale because it has been open for 30 days without activity. Remove the stale label or comment, or this will be closed in 7 days.