[Static-context Paradigm] How to handle errors in `on context changed`

[toddbaert]

In static-context-paradigm (aka client paradigm), the provider context-changed handler runs to help reconcile the new global context with the provider's state (and in many cases the underlying SDK's state). This likely involves doing some kind of conversion of the context. It's reasonable for this function to throw an error, or otherwise signal an abnormal termination.

We haven't defined how this should be handled. I see the following options:

• throw/indicate an error in the setContext, ie: bubble up the error, and leave the context unchanged
  • we'd have to make it clear this method could "fail"; I think this is still consistent with our paradigm of not throwing during evaluation since this isn't an evaluation
• transition the provider to an error state and run the error handlers
  • in these case the OpenFeature context is left in an "unreconciled" state, which could be problematic

[!NOTE]
I don't believe this is relevant to dynamic-context aka server-side SDKs and providers, which do this sort of conversion within the evaluation flow.

cc @jonathannorris @moredip @lukas-reining @beeme1mr @fabriziodemaria @vahidlazio @thomaspoignant @kinyoklion

[Kavindu-Dodan]

I also agree that this does not apply to dynamic-context usage.

For static context, given context change is an important event, I am in favor of the throw/indicate error approach. I do not think SDK should enforce a state transition as the decision of such change is up to provider implementation.

[thomaspoignant]

@toddbaert I'll bring back this conversation since this is a similar discussion than the one we have in the implementation of the OFREP provider here https://github.com/open-feature/js-sdk-contrib/pull/776#discussion_r1546376895.

In my case, we have received a 429 that asks to retry later, but before the retry date we have a change in the context. In such case, my implementation keeps the provider in error and will not try to call the flag management system, but that puts the provider in a state where it does not react to a context change (even if he will eventually do it with the polling mechanism),

But the setContext will silently do nothing on the moment. Is this what we want in such case?