iOS LaunchDarklyTimeoutError identify timed out after 5 seconds.

[Traviskn]

Describe the bug After upgrading to @launchdarkly/react-native-client-sdk version 10.2.0, we have seen around 12% of our iOS users get an identify timeout error. In contrast, only about 1% of our Android users are getting the timeout error. For some reason the iOS platform is seeing a much higher magnitude of identify timeout errors. We have a nearly equal number of active users between platforms, the sample size is not significantly different.

To reproduce Configure the launch darkly SDK and identify the user at app startup. Observe the rate of timeout errors, notice that the iOS platform is about 10% higher than the Android platform.

Expected behavior The identify call should time out at about the same rate between platforms.

Logs We utilize bugsnag for error tracking, here are the logs from a production error event:

LaunchDarklyTimeoutError identify timed out after 5 seconds. 
    (native) construct
    (native) apply
    node_modules/.pnpm/@babel+runtime@7.24.1/node_modules/@babel/runtime/helpers/construct.js:4:65 _construct
    node_modules/.pnpm/@babel+runtime@7.24.1/node_modules/@babel/runtime/helpers/wrapNativeSuper.js:17:23 Wrapper
    (native) construct
    node_modules/.pnpm/@launchdarkly+js-sdk-common@2.5.0/node_modules/@launchdarkly/js-sdk-common/dist/errors.js:4 _createSuperInternal
    (native) call
    node_modules/.pnpm/@launchdarkly+js-sdk-common@2.5.0/node_modules/@launchdarkly/js-sdk-common/dist/errors.js:46:8 LDTimeoutError
    node_modules/.pnpm/@launchdarkly+js-sdk-common@2.5.0/node_modules/@launchdarkly/js-sdk-common/dist/utils/timedPromise.js:13:43 anonymous
    (native) apply
    node_modules/.pnpm/react-native@0.73.5_@babel+core@7.24.3_@babel+preset-env@7.24.3_react@18.2.0/node_modules/react-native/Libraries/Core/Timers/JSTimers.js:213:23 anonymous
    node_modules/.pnpm/react-native@0.73.5_@babel+core@7.24.3_@babel+preset-env@7.24.3_react@18.2.0/node_modules/react-native/Libraries/Core/Timers/JSTimers.js:111:15 _callTimer
    node_modules/.pnpm/react-native@0.73.5_@babel+core@7.24.3_@babel+preset-env@7.24.3_react@18.2.0/node_modules/react-native/Libraries/Core/Timers/JSTimers.js:359:17 callTimers
    (native) apply
    node_modules/.pnpm/react-native@0.73.5_@babel+core@7.24.3_@babel+preset-env@7.24.3_react@18.2.0/node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:433:34 __callFunction
    node_modules/.pnpm/react-native@0.73.5_@babel+core@7.24.3_@babel+preset-env@7.24.3_react@18.2.0/node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:113:26 anonymous
    node_modules/.pnpm/react-native@0.73.5_@babel+core@7.24.3_@babel+preset-env@7.24.3_react@18.2.0/node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:368:11 __guard
    node_modules/.pnpm/react-native@0.73.5_@babel+core@7.24.3_@babel+preset-env@7.24.3_react@18.2.0/node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:112:17 callFunctionReturnFlushedQueue

SDK version @launchdarkly/react-native-client-sdk 10.2.0

OS/platform iOS

[Traviskn]

We wrapped our identify call in a helper that retries if it fails and we are now seeing a much lower failure rate

[kinyoklion]

The identify method takes options and allows you to configure the timeout , {timeout: 30}. Generally speaking indefinitely waiting for identify isn't a safe practice in case there is a network problem or outage.

The SDK should continue to retry even after the timeout, if it is not, then that is a bug and we need to look into it. We will look into it and validate.

Thank you, Ryan

[kinyoklion]

There are upcoming connection handling improvements, but the ability of identify to timeout is as designed.