When bootstrapping a non valid object, it still resolves immediately

[lukeapage]

Describe the bug
When bootstrapping but the server is offline a $valid: false property is set:
https://github.com/launchdarkly/js-sdk-common/blob/master/src/index.js#L105

And you warn about that. But despite it not being valid and being an empty object, you do not wait for speaking to launch darkly and waitForInitialization resolves early, leaving an empty feature flag set.

Expected behavior
I expect if the bootstrap is not valid to behave as if it is not set.

We workaround this by checking $valid ourselves - but I don't think we should have to.

SDK version
The client api - 2.17.0

[eli-darkly]

Hi - I think I need a little more information about exactly what you are doing on the back end. The $valid property is normally set at the time that you call allFlagsState() in a server-side SDK. If the server is offline at that point then I'm not sure why you are passing a bootstrap object to the front end at all.

[lukeapage]

If we have an issue on the backend server (at the moment we’re fighting production proxy issues) then it’s meant to be online, but it isn’t so it’s seeding the front end with invalid values.

And I was thinking the same could happen even once we fix our proxy issue if for instance there is a problem on our proxy or firewall.

[lukeapage]

The dotnet sdk examples don’t suggest checking a is online like property before calling all flags state?

[eli-darkly]

Well, the property you would check if you were going to check something is the Valid property on the FeatureFlagsState object. That is the programmatic way to see if you really have values, corresponding to the $valid property in the JSON.

I understand not wanting to have to check anything, but I'm not sure it is correct to say that the default front-end behavior should be to ignore the values and contact the LaunchDarkly service instead if $valid is false. Setting a bootstrap object at all implies that you are telling the front-end SDK to use that, and only that. That's how the method is documented; I'm not sure what in the docs would lead you to expect that it would ignore the object. And I'm not sure it's desirable for it to do so; the front-end SDK has no way to know whether "the back-end server can't reach LaunchDarkly" implies "but maybe I could reach LaunchDarkly" or not. In some applications the developer might not want the front end to ever try to connect to LD at all, due to network restrictions for instance.

[lukeapage]

I don’t mind checking something but your documentation and example don’t - so it’s confusing.

I’m just trying to help your future customers from confusion and bugs - please feel free to close this and if you consider I have a point to fix your examples/documentation.