Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
angelo-hub opened this issue Apr 18, 2024 · 3 comments
Labels
bug Something isn't working package: sdk/react-native Issues that affect the react native SDK. waiting for feedback Indicates LaunchDarkly is waiting for customer feedback before issue is closed due to staleness.

Comments

@angelo-hub
Copy link

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

@angelo-hub angelo-hub added bug Something isn't working package: shared/common Label for issues affecting the shared/common package. labels Apr 18, 2024
@yusinto
Copy link
Contributor

yusinto commented Apr 22, 2024

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.

@yusinto yusinto added the waiting for feedback Indicates LaunchDarkly is waiting for customer feedback before issue is closed due to staleness. label Apr 22, 2024
@kinyoklion kinyoklion added package: sdk/react-native Issues that affect the react native SDK. and removed package: shared/common Label for issues affecting the shared/common package. labels Apr 23, 2024
@Ardhimas
Copy link

@yusinto there is some discussion on the Detox E2E testing framework issue tracker that may be relevant to this issue:
wix/Detox#3443 (comment)

@yusinto
Copy link
Contributor

yusinto commented Apr 25, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working package: sdk/react-native Issues that affect the react native SDK. waiting for feedback Indicates LaunchDarkly is waiting for customer feedback before issue is closed due to staleness.
Projects
None yet
Development

No branches or pull requests

4 participants