Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
toddbaert opened this issue Nov 3, 2023 · 2 comments
Open

Comments

@toddbaert
Copy link
Member

toddbaert commented Nov 3, 2023

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
Copy link
Contributor

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
Copy link
Member

@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 open-feature/js-sdk-contrib#776 (comment).

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants