launchdarkly / js-core

LaunchDarkly monorepo for JavaScript SDKs
Other
10 stars 11 forks source link

[React-Native Package] Android Package producing "Application Not Responding" Error Events #441

Open angelo-hub opened 1 month ago

angelo-hub commented 1 month ago

Is this a support request?

Describe the bug On Android the SDK seems to be a source of a jump in Application Not Responding Errors [currently on @launchdarkly/react-native-client-sdk@10.0.3]

To reproduce We call client.identify in a useEffect, that runs when the user is anonymous opening the app, then again when the user logs in or logs out

  React.useEffect(() => {
    const setup = async () => {
      let context: LDContext;

      if (!userId) {
        context = deviceContext;
      } else {
        const userContext: LDContext = {
          key: userId,
        };

        context = {
          device: deviceContext,
          kind: 'multi',
          user: userContext,
        };
      }

      await featureClient
        .identify(context)
        .catch((e) => console.error('[LaunchDarkly] ', e));
      console.log('[LaunchDarkly] Identified User as: ', context);
    };
    setup();
  }, [userId]);

On android it seems that calling identify is causing lockup when our next rendered viewed includes a useBoolVariation hook

Expected behavior Expect no frozen frames or Application Not responding events when both calling identify, and mounting a useBoolVariation hook in a short timetable

Logs

We use socket.io as our main means of communicating with our backend and within our datadog sessions logs we see the clientStream XHR request almost blocking our socket.io events or atleast causing the UI to slow to a degraded state.

Screenshot 2024-04-18 at 10 40 04 AM

we suspect this could be triggering more frequently for users with bad network connections on android.

we also have one usage of the featureClient that doesn't utilize a hook and updates a state like so:

  React.useEffect(() => {
    if (!featureClient || !isLaunchDarklyEnabled) {
      return;
    }
    const featureFlag = featureClient.boolVariation(
      'disable-some-feature',
      false,
    );
    setSomeReactState(featureFlag);
  }, [isLaunchDarklyEnabled]);

where isLaunchDarklyEnabled is a shared React.Context

SDK version The version of this SDK that you are using.

Language version, developer tools React-Native: 0.72.7 Expo: 49.X socket.io: 5.0.22

@launchdarkly/react-native-client-sdk@10.0.3

OS/platform For instance, Ubuntu 16.04, Windows 10, or Android 4.0.3. If your code is running in a browser, please also include the browser type and version.

Additional context

Tried several other means of debugging and triaging this issue before ending up at the point of believing that LaunchDarkly is impacting the performance, the change in between versions that caused this drop was adding useBoolVariation to a hook that mounts.

Updating to latest seems to alleviate the issue by triggering the new timeout to the identify function however, it also causes our homepage to be missing components hidden behind LD flags

yusinto commented 1 month ago

useBoolVariation calls variationInternal under the hood, and is designed to be a fast synchronous call. It should not block. It returns the default value if identify is unfinished.

identify is an async operation, and depending on how you use it, it may block your application. The timeout option is designed to deal with long delays. In general, we recommend using sensible defaults for your applications to avoid missing components in cases of slow/network delays.

The sdk doesn't emit Application Not Responding errors. This sounds like it maybe coming from your own application code, or some other third party library. Maybe socket.io? You can try setting debug to true to see additional error logs to investigate this.

Please contact our support team if you have further issues and questions.

Ardhimas commented 1 month ago

@yusinto there is some discussion on the Detox E2E testing framework issue tracker that may be relevant to this issue: https://github.com/wix/Detox/issues/3443#issuecomment-1328213683

yusinto commented 1 month ago

That issue is caused by detox waiting for network connections to close in a test. I responded there to exempt the streaming uri from this wait. I don't think detox is the cause of the issue in this issue.