-
Notifications
You must be signed in to change notification settings - Fork 39
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
[FEATURE] Evaluation Context behavior is suprising #939
Comments
@jhollanderpax8 I think this is related to #940. Like I said in my response 1 OpenFeature defines multiple context levels (ex:- API, transaction, client, evaluation). And each of them are merged prior to a flag evaluation. If you intend to set an API level context, that is valid to all underlying entities derived from OpenFeature API (ex:- clients, hooks ), then you can use example below as a reference, OpenFeatureAPI api = OpenFeatureAPI.getInstance();
api.setEvaluationContext(new ImmutableContext(Map.of("foo", new Value("Bar"))));
final Client client = api.getClient();
client.getBooleanDetails("booleanKey", false); Here the API context Footnotes |
@Kavindu-Dodan thanks for the reply. In my testing this didn't seem to be true. I was uncertain if I should file it as a bug because it wasn't 100% clear from the docs that it should be. I will make sure I can reproduce it in a small test and then open a bug report if I can. |
@jhollanderpax8 sure feel free to. Please also check the the SDK version. |
@jhollanderpax8 I think part of the issue here is we are missing some Javadoc. We also are missing a very specific test for setting global context (it's covered, but only as part of other tests). I've opened a PR that adds missing javadocs, and also adds a test specifically asserting that global context is used in evaluations. |
I was able to confirm that it works as expected and the error was in some Kotlin extension function hackery I was doing. I still consider ImmutableContext to be awkward in light of ThreadLocalTransactionPropagator, but I am likely going to likely using Kotlin extension functions to make the API more ergonomic as the basic abstractions are solid if awkward to work with. Thanks the clarification and documentation updates/test cases. |
The typescript examples in the OpenFeature docs show this snippet:
Leading one to believe that a similar approach would work with the Java SDK, however this is not true and it's very surprising behavior if you are used to things like MDC context in Log4j.
One would expect this to work:
but instead you must do
Which IMO is surprising and inconsistent behavior and makes context propagation less than useful.
The text was updated successfully, but these errors were encountered: