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

Open
#214 2 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Domain
api, backend-api-design

Research direction

Start with the provider context reconciliation section linked in the issue and review the existing setContext behavior for static-context providers. Compare the proposed error-handling options and determine the intended treatment of failed reconciliation. Done means the specification clearly defines the behavior and resulting provider or context state.

Written by the indexing model from the issue text.

Description

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

Dominant language
Python
Stars
1.3k
Forks
58
Avg merge
2d 18h
Merged PRs (30d)
2

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from open-feature/spec

All issues in open-feature/spec

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.