launchdarkly/react-native-client-sdk

Identify does not have a timeout property(request hangs)

Opened this issue · 5 comments

OrLevy23 commented

It appears that identify method does not have a timeout (connectionTimeout does not seem to work)
I was able to reproduce while device is offline identify request hangs forever
In my suspicion this causes our app to hang upon launch as we are waiting for identify in order to evaluate feature flags.

we are using: "launchdarkly-react-native-client-sdk": "^7.1.4",

please assist as this is a critical issue for us that might cause us to stop using launchdarkly completely(also we need to make sure that all rest of requests does have a timeout as well)

tanderson-ld commented

HI @OrLevy23, thank you for taking the time to submit this issue. Do you see this issue on both iOS and Android or just one of them? We have filed investigating this internally under 207173.

For our info:

  1. In your use case, what would you like to happen after a timeout triggers?

To help get you unblocked:
2. Are you using configure as well as a identify at app launch? Usually only configure is used at launch and that may be a short term solution, though in the offline case it will be using cached evaluation logic if the user/context is the same as last run.

OrLevy23 commented

Hey, @tanderson-ld ,

  1. I was able to reconstruct this on both android and ios.
  2. would probably get a timeout + fallback to anonymous user.
  3. at app launch we call identify for anonymous user (if user is not logged in) and we call identify the second time when he logs in.
OrLevy23 commented

Also I would probably expect some kind of a retry mechanism to apply here (exponential retry mechanism would be probably best)

OrLevy23 commented

any updates here? @tanderson-ld

tanderson-ld commented

Hi again @OrLevy23. I spent some time trying to reproduce this and was unable to get the identify method to hang. Is it the identify method itself that is hanging or is it the promise triggering that never happens?

I was also unable to get the promise returned from identify to hang indefinitely, however I was able to get the promise to take up to around 90 seconds to fire which is certainly not an option in your use case. Under the hood the SDKs will retry fetching the latest flag data.

Myself and others discussed your feedback and also reviewed another related issue on the Android SDK. This is the link to that related issue. We agree that the behavior/communication of errors during init and identify needs to be improved and the addition of a timeout is useful. It sounds like you would prefer what others in that link issue would prefer which is a blocking call that guarantees latest flags or an error on timeout. I will work with my team members to prioritize that work into our timeline, but to be up front and honest, it may be some time as we are executing on other work.

In the interim, you may have to create timeout logic around the promise returned from identify.