flagsmith icon indicating copy to clipboard operation
flagsmith copied to clipboard

Frontend gets stuck if a Flagsmith on Flagsmith call fails

Open khvn26 opened this issue 9 months ago • 6 comments

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.

khvn26 avatar Mar 05 '25 19:03 khvn26

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.

matthewelwell avatar Mar 13 '25 11:03 matthewelwell

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.

kyle-ssg avatar Mar 25 '25 16:03 kyle-ssg

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

AudriusButkevicius avatar Jun 11 '25 12:06 AudriusButkevicius

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.

khvn26 avatar Jun 11 '25 12:06 khvn26

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.

AudriusButkevicius avatar Jun 12 '25 07:06 AudriusButkevicius

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.

tiagoapolo avatar Jun 13 '25 18:06 tiagoapolo

Blocked by https://github.com/Flagsmith/flagsmith-js-client/issues/320

matthewelwell avatar Jun 20 '25 10:06 matthewelwell