fix: Handle uncaught fetch exception

[frankieyan]

Closes #249

When the local cache is populated or when default flags are provided, flagsmith.init does not reject if the call to edge proxy fails; however, an uncaught exception gets thrown which is difficult to catch in user code. This change allows the error to be caught within Flagsmith (logging Exception fetching cached logs when verbose mode is on).

[frankieyan]

Hi @matthewelwell, would you be able to take a look at this one please?

[kyle-ssg]

Hmm I'm not sure I understand this, if we await the api call this makes the cache useless since awaiting flagsmith.init would block until the API returns a response?

[frankieyan]

Hmm I'm not sure I understand this, if we await the api call this makes the cache useless since awaiting flagsmith.init would block until the API returns a response?

That's what I realized just now looking at the failed test. Nice catch! 👍

[kyle-ssg]

Hmm I'd be interested in knowing what your ideal solution would be to the issue. Is the purpose of this so you can surface error logs?

The thrown exception will cause onError to call

flagsmith.init({onError:()=>})

[frankieyan]

So the crux of the issue for us is that the thrown error can't be handled outside of Flagsmith. It doesn't reject the promise returned from init, nor does it call onError. This triggers an unhandled exception and turns out is lighting up our Sentry.

As for the error itself, I don't think we're too interested in tracking or handling it as it's likely just due to network flake.

Edit: An alternative could be to do as you suggest: pass onError to getFlags so that it does get called. Is that something you'd prefer?

[kyle-ssg]

Yeah I think it should definitely call on error, so that'll need fixing. From what I understood it did since init is all wrapped in a try catch that calls onError

[kyle-ssg]

@frankieyan Could you check whether adjusting to the following works for you

   // We want to resolve init since we have cached flags
    this.getFlags().catch((err) => {
     throw err // triggers call to onError
   });

[frankieyan]

@frankieyan Could you check whether adjusting to the following works for you

   // We want to resolve init since we have cached flags
    this.getFlags().catch((err) => {
     throw err // triggers call to onError
   });

@kyle-ssg no, that still results in the floating promise being rejected. Looks like calling onError explicitly works though.

If this approach (in 464c3ed) looks good to you, I'll come back tomorrow and add a test case for when it calls /identities/ as well, as I believe right now the new test cases are only hitting /flags.

[kyle-ssg]

Ok yep that works for me - let's go with that

[matthewelwell]

@frankieyan , just checking in to see if you're still able to add the test case as discussed with @kyle-ssg above?

[frankieyan]

Hey @matthewelwell! I've been a bit swamped recently but aiming to come back to it next week 👍

[gnapse]

@matthewelwell I'm helping Frankie on this one. Can you review the last commit and see if this is what's needed?

Update: my editor applied incorrect code formatting. I'll fix it.

Update 2: I fixed it, it looks like this file was not fully following prettier config, and its formatting had diverged from the prettier settings. I applied the formatting in one commit, and then the new test case in the last commit.