[BUG] READY -> NOT_READY race condition (@openfeature/react-sdk@0.2.3-experimental)

[malinskibeniamin]

Observed behavior

Background: We use an experimental React SDK package @openfeature/react-sdk, as well as LaunchDarkly OpenFeature client provider from @openfeature/launchdarkly-client-provider. At the app's root level, we initialize context with

await OpenFeature.setProviderAndWait(provider);

before rendering any feature-flagged content.

When calling

const client = useOpenFeatureClient();

client?.providerStatus yields NOT_READY after it already transitioned to READY, this happens roughly once in about 10 times.

We are using the following settings for the feature flag.

  const enableSomeFeatureFlag = useBooleanFlagValue(
    flagKey,
    false,
    {
      suspendUntilReady: true,
      updateOnConfigurationChanged: true,
      updateOnContextChanged: true,
    }
  );

The component that contains the provider status call is wrapped in a Suspense, checking whether client?.providerStatus === 'READY' before continuing with feature flag checks.

If NOT_READY -> READY transition occurs, it triggers a re-render for the component and the flags are properly evaluated.

If NOT_READY -> READY -> NOT_READY transition occurs, it does not trigger a subsequent re-render.

This cannot be reproduced easily through DevTools, because time delay caused by debugging prevents the race condition.

Expected Behavior

When the component has loaded, the provider should not go from READY to NOT_READY state, but rather newly introduced RECONCILING or similar if the feature flag context needs to be re-evaluated for some reason.

Alternatively, ensure that going back to NOT_READY state (if allowed) should always re-evaluate a context, triggering a re-render.

At the moment, we don't have an easy way to force the reconciliation to ensure the feature flags will not fall back to their default values.

Steps to reproduce

Previous packages:

"@openfeature/launchdarkly-client-provider": "latest",
"@openfeature/react-sdk": "^0.1.0-experimental",
"@openfeature/web-sdk": "^0.4.10",

Updated packages (error manifested after this update):

"@openfeature/core": "^1.0.0",
"@openfeature/launchdarkly-client-provider": "^0.3.0",
"@openfeature/react-sdk": "^0.2.3-experimental",
"@openfeature/web-sdk": "^1.0.1",

[toddbaert]

Without an exact snippet of code, I can't say for sure why you're seeing this. I have a few suggestions and a few questions.

Suggestions:

• If you're using suspense, don't await OpenFeature.setProviderAndWait(provider);, suspense should take care of preventing rendering for you, especially if you are on React v18 and using the new createRoot method instead of render.
• If you're using suspense, don't use useOpenFeatureClient(); and manually check readiness at all if you can help it, just use the feature flag hooks (useBooleanFlagValue, etc) directly which will cause suspense.
• Ensure that you are not creating multiple provider instances or setting the provider more than once! I've seen people do this accidentally by doing these in render functions, for instance. Try adding a console.warn where you create/set your provider and make sure you only see it warn once.
• If you're using npm, ensure you've only manually instead the @openfeature/react-sdk and the @openfeature/launchdarkly-client-provider; the @openfeature/web-sdk and @openfeature/core peer deps will be installed automatically at the correct versions. With yarn you have to do that manually, and with pnpm you can configure it to behave like npm.

Questions:

• What version of react are you using?
• What package manager are you using?

I also suggest you check out the demos here, particularly https://github.com/open-feature/react-test-app/blob/main/src/demos/SuspenseDemo.tsx.

[toddbaert]

Hey @malinskibeniamin , don't want to bug, but any update on this?

[malinskibeniamin]

Hi @toddbaert, thanks for the reminder. Unfortunately at the moment I'm quite busy, hopefully I can revisit this next week. If you don't mind maybe we can keep this issue open for now

[toddbaert]

Hi @toddbaert, thanks for the reminder. Unfortunately at the moment I'm quite busy, hopefully I can revisit this next week. If you don't mind maybe we can keep this issue open for now

Absolutely! No rush and no problem. I'll certainly keep this open until I hear back from you. If I find anything myself I'll follow up.

[toddbaert]

Closing for inactivity. Please comment if you want to re-open.