Warning logged about omitting identify when client is bootstrapped

[jakepeyser]

Describe the bug
When I bootstrap the JS SDK client with flags hydrated from SSR and include my user context, I still see a warning log printed to the dev console that reads:

[LaunchDarkly] Be sure to call identify in the LaunchDarkly client: https://docs.launchdarkly.com/sdk/features/identify#javascript

I don't expect to have to call identify here as I've already established my context for the session.

To reproduce

1. Initialize the client with a context and { bootstrap: flags } option
2. Call variation with that client

Expected behavior
I would expect no warning logs if the context was set during client initialization

Logs

[LaunchDarkly] Be sure to call identify in the LaunchDarkly client: https://docs.launchdarkly.com/sdk/features/identify#javascript

SDK version
"launchdarkly-js-client-sdk": "^3.1.3"

OS/platform
MacOS Monterey 12.6.2, Google Chrome 112.0.5615.137

[kinyoklion]

Hello @jakepeyser,

It would appear this is because a variation call is made during the initialization, which isn't completed by the time the init call returns. I double checked this by doing a variation call after initialization was complete, not seeing this error. Then I did another trial where I did a variation call before initialization was complete and observed this error.

The intialization won't wait for a polling connection when bootstrap data is provided, but it still does some asynchronous work. This work is primarily related to context validation, during which a context key may be generated and persisted for anonymous contexts.

Is this a difference in behavior noted in a version upgrade, or is this an initial implementation?

Thanks,
Ryan

[jakepeyser]

Hey @kinyoklion,

Thanks for the quick response! I've been seeing this warning since I set up my new project back in January, but I'm only now just getting around to optimizing how the LD client is bootstrapped.

I'd like to get the variation straight away given that the client has already been bootstrapped and should contain the correct values based on the initial context. I don't see why context validation would change the output of that call, so whether the client is ready or not by the time I call variation seems irrelevant.

Since I have the initial flags, I could delay my call to variation until I get a "ready" event from the client, but it feels unnecessary to me. Am I thinking about this in the wrong way?

[kinyoklion]

@jakepeyser The variation will remain the same regardless. The effect would be if you were using any features that depend on the analytics events. For instance, if you were trying to do an experiment, then the back-end would not be able to determine percentages for different variations.

I do understand the desire to evaluate the flag immediately. I can not say for sure, but it may be possible to set the context earlier in the case where it was A.) Passed during initialization, and B.) Has a provided key and doesn't require a generated one.

I am not sure if we could make that a guaranteed part of the interface though.

Thanks,
Ryan

[jakepeyser]

Ahh thank you for that explanation, it makes sense for that use case. We unfortunately aren't using experiments right now, so it sounds like out setup is fine.

I am passing the context during init and the key is always provided as we share a key for anon users. What would you suggest we do given our use case?