[BUG] optimizely.isReady() always returns false in version 3.2.3

[mlazari]

Is there an existing issue for this?

• I have searched the existing issues

SDK Version

3.2.3

Current Behavior

If I use a OptimizelyProvider that on first render has user undefined, then the isReady() method of the optimizely client will always return false, even if the user is set later.
It seems to be related to this change that added verification for isUserReady to isReady(): 62a12ff#diff-25d66d74617fe2e23d7946bd6e3ba95640ab1b9bc8947445d604fc271c7c1f12R447

isUserReady seems to be changed only once here - https://github.com/optimizely/react-sdk/blob/3.2.3/src/client.ts#L252 - after userReadyPromise is resolved here when setUser is called first time (e.g. from OptimizelyProvider) - https://github.com/optimizely/react-sdk/blob/3.2.3/src/client.ts#L410. If setUser was called with the default user (with id = null), then the promise gets resolved with { success: false }, thus isUserReady will remain false and never change again.

Expected Behavior

isReady() should return true at some point when the optimizely client is ready.

Steps To Reproduce

1. Clone https://github.com/mlazari/OptimizelyRepro and make sure you are in the main branch
2. Copy the .env.development file to a new .env.local file in the root of the project and set your optimizely key in it
3. Run npm install
4. Run npx expo prebuild --clean
5. Run the app with npx expo run:ios (or npx expo run:android)
6. Tap on the "Re-check" button, see the "Optimizely Ready" field remains false. Try again by tapping on "Set user info", then again on "Re-check", see it still says "false"

3.2.3.mp4

7. Close the app and metro bundler
8. Switch to branch 3.2.2 (which has @optimizely/react-sdk downgraded to 3.2.2)
9. Run npm install
10. Run npx expo prebuild --clean
11. Run the app with npx expo run:ios (or npx expo run:android)
12. Tap on the "Re-check" button, see the "Optimizely Ready" field changes to true

3.2.2.mp4

React Framework

No response

Browsers impacted

No response

Link

https://github.com/mlazari/OptimizelyRepro/blob/main/app/index.tsx

Logs

No response

Severity

Blocking development

Workaround/Solution

Downgrading to 3.2.2 for now.

Recent Change

No response

Conflicts

No response

[junaed-optimizely]

Hey @mlazari , thanks for very detailed report.

I gave it a look. {success: false} happens when ODP is explicitly disabled and user is set to default user.

Expected behavior is - "User promise should not be fulfilled unless a valid user is set, when ODP is disabled".

This is an edge case that has not been considered in the SDK for a while. v3.2.3 just exposed it.

I have created an internal ticket FSSDK-10980 to track this. Will get back to it shortly!

Thanks again.

[mlazari]

@junaed-optimizely Thank you! I was also thinking it's related to ODP being disabled, but from my debugging it was not reaching the this.odpExplicitlyOff verification at https://github.com/optimizely/react-sdk/blob/3.2.3/src/client.ts#L377C9-L377C30 because it was returning earlier at https://github.com/optimizely/react-sdk/blob/3.2.3/src/client.ts#L374 because userContext was null. But I guess it was null because of ODP being disabled?

[junaed-optimizely]

Yes. The underlying JS SDK client _client.createUserContext returns null
React ref -

react-sdk/src/client.ts

Line 342 in ddadd3e

this.userContext = this._client.createUserContext(userInfo.id || undefined, userInfo.attributes);

JS ref -
https://github.com/optimizely/javascript-sdk/blob/973cbf7b41e4ec31cd918dc69b045e97e81d0540/lib/optimizely/index.ts#L1464