Frontend gets stuck if a Flagsmith on Flagsmith call fails

[khvn26]

Currently, the offline defaults are only being used if the FoF base url and environment key are not being set. If they are set, but the SDK API call fails with a e.g. 403 error, the frontend gets stuck.

We need to be more permissive and fall back to the offline defaults on failing FoF SDK API fetches.

[matthewelwell]

Discussing with @khvn26 , and referring to a conversation in Slack, there seems to be some different scenarios in which this is an issue as it is not the case all of the time. We should check all scenarios of setting / unsetting the environment variables with valid / invalid keys and URLs.

[kyle-ssg]

We currently have a hard dependency on the flagsmith SDK, it looks like we recently added default fallbacks to a couple flags but that's at evaluation time rather than telling the SDK to use these if the API calls fail.

The problem I see is If we supply a half-baked set of default flags is that it could lead to unpredicted results. The best solution I can think of is to hit the "Self Hosted Defaults" for docker and "Production" for SaaS in CI and initialise the SDK with that.

Even if we do the above, this would:

• For self-hosted lead to unexpected results if a self-hosted instance had a different set of flags or.
• For SaaS revert to slightly older flags if the SDK endpoint is unavailable for a user.

[AudriusButkevicius]

Is there a list of things to set to get past this issue? Happy to be a guinea pig.

[khvn26]

Even if we do the above, this would:

For self-hosted lead to unexpected results if a self-hosted instance had a different set of flags or.
For SaaS revert to slightly older flags if the SDK endpoint is unavailable for a user.

We could add a butter bar warning that the FoF call was unsuccessful. I think it's much better than current broken behaviour. FoF flags shouldn't affect evaluation anyway, so they're not critical.

[AudriusButkevicius]

I've tried setting flagsmith on flagsmith env vars to empty strings in my docker compose, however, that just throws the UI into maintenance mode. I think the check for dark theme fails, and sets store.error = true, which then sends to maintenance mode. If I add a breakpoint and set the error to false, it skips past the maintenance view and sends the ui back into infinite spinner, which is what I had before setting any env vars. I cannot see any calls going out anywhere that fail in the network tab, I can't see anything logged in the developer console either that would explain this.

[tiagoapolo]

After further investigation, we need to handle more effectively errors, IMO we don't want the maintenance screen to show and have an infinite spinning loader. Also, we should use the onError callback from the SDK in order to tell if FoF was unsuccessful. So first step is to improve error handling in the SDK and then handle the FoF in the dashboard.

[matthewelwell]

Blocked by Flagsmith/flagsmith-js-client#320