waitForInitialization should wait until flags have been initialized

[RedbackThomson]

Is your feature request related to a problem? Please describe.
Using the SDK, we sometimes randomly run into a situation where we are evaluating a flag right after the page is loaded. In the LaunchDarkly support documentation, the FLAG_NOT_FOUND is caused by the cache not yet being populated by the client. From diving into the code, it appears that the waitForInitialization does not wait until flags have been initialized from the LD service before it resolves (only from the bootstrap).

Describe the solution you'd like
waitForInitialization should wait for flags to have been loaded from the service (in my case, the stream) before resolving.

Describe alternatives you've considered
I have struggled to find any way to determine whether flags have been loaded, since all of this is abstracted away behind higher levels of the SDK.

Additional context
Add any other context about the feature request here.

[kinyoklion]

The waitForInitialization function only waits for initialization. Any source of flags, including bootstrap, completes initialization. Many application only initialize the SDK with bootstrap data and do not subsequently establish a streaming connection. The default behavior of the SDK would be to not establish any connection at all, and only opting into streaming (via config or an event handler) results in an additional connection.

Bootstrap is intended to be generated using the same context on a server as will be evaluated on the client, and should have all the same flags as a payload that the client receives. This would typically happen immediately before initialization either via server-side rendering, or something like a payload from an authentication request.

What is the use case of the bootstrap data in this situation which results in it not containing the correct flag payload?

Thank you,
Ryan

[RedbackThomson]

It's been difficult to reproduce the exact error but I can try to describe the context around this ask. From what we've seen, when changing a flag targeting rule in the LD console, the subsequent page load often fails to evaluate the flag - returning FLAG_NOT_FOUND. From logging the evaluated responses I saw that the FLAG_NOT_FOUND is returned for the initial anonymous context as well as any subsequent context that is set. I'm using the LD SDK behind the OpenFeature provider, which blocks suspense until the provider resolves waitForInitialization. When this error occurs, the suspense is never lifted, which causes our page to stay in the fallback loading state.

Please correct me if I'm misinterpreting, but my hunch was given we are busting the LD server flag cache (by updating a targeting rule), the LD APIs takes longer than normal to respond and therefore the waitForInitialization was resolving before the new flag settings are being streamed into the cache. Since waitForInitialization is resolving, the OpenFeature provider begins trying to evaluate from the empty cache and resolves all evaluations to FLAG_NOT_FOUND.

If that theory is correct then maybe having a separate method to wait until the flags have been populated by the stream, or updating waitForInitialization to have this as another condition before resolving, would solve the problem.

The one issue with my theory is that OpenFeature only requires waitForInitialization to resolve before lifting the suspense boundary, so I'm not sure why the pages stays in the loading state indefinitely. However, that issue only occurs when the FLAG_NOT_FOUND errors occur - so they must be linked in some way.

[RedbackThomson]

This would typically happen immediately before initialization either via server-side rendering, or something like a payload from an authentication request

Unfortunately this isn't something we can do in our application. We are setting context using a useEffect() inside the React application, and our data isn't exposed back to the server since it's all inherently client-side.

[kinyoklion]

There has been additional conversation outside github for this. Once further context is available the ticket should be updated.

[RedbackThomson]

Based on our conversation on the CNCF Slack, I think the problem actually stems from the fact that LD Client was never timing out if it failed to connect to the server during initialization. This ultimately caused the OpenFeature provider to stall and therefore all flags evaluated to FLAG_NOT_FOUND (which rather confusingly OF uses as their error message as well as LD). Now that the LD provider supports configuring a timeout, hopefully this doesn't happen again.