feat: Add async functionality to providers #413

leohoare · 2025-01-12T08:48:42Z

This PR

Adds the ability for open feature providers to use async methods
It extends the single client and attempts to refactor some code

Related Issues
#284
#383
#385

Follow-up Tasks & TODOS

Add tests for async provider and implementation
Add documentation and how to implement an async hook

codecov · 2025-01-13T15:24:49Z

Codecov Report

Attention: Patch coverage is 97.80564% with 7 lines in your changes missing coverage. Please review.

Project coverage is 97.72%. Comparing base (c2d1402) to head (e7b951e).

Files with missing lines	Patch %	Lines
tests/provider/test_provider_compatibility.py	90.54%	7 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #413      +/-   ##
==========================================
+ Coverage   97.55%   97.72%   +0.16%     
==========================================
  Files          31       32       +1     
  Lines        1393     1629     +236     
==========================================
+ Hits         1359     1592     +233     
- Misses         34       37       +3

Flag	Coverage Δ
unittests	`97.72% <97.80%> (+0.16%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

beeme1mr · 2025-01-13T15:36:24Z

Hey @leohoare, this looks good so far. Could you please add tests covering async providers with sync client calls and vise versa? Thanks for your hard work on this. 🍻

leohoare · 2025-01-22T22:10:35Z

Thanks @beeme1mr, I've added some tests and addressed the coverage issues.

One thing to note is sync methods are always enforced on async providers.
you can't implement an async only provider, although, you can work around this unless using NotImplementedError on the sync methods. It was implemented on the AbstractProvider to keep current functionality the same.

Is this clear enough from the documentation?

beeme1mr · 2025-01-23T22:37:34Z

Thanks @beeme1mr, I've added some tests and addressed the coverage issues.

One thing to note is sync methods are always enforced on async providers.
you can't implement an async only provider, although, you can work around this unless using NotImplementedError on the sync methods. It was implemented on the AbstractProvider to keep current functionality the same.

Is this clear enough from the documentation?

Sorry, I didn't get a chance to look at this today. It's on my to-do for tomorrow.

leohoare · 2025-01-23T22:44:44Z

No rush, I'll be off grid over the weekend anyway.

beeme1mr

Hey @leohoare, this looks good from what I can tell but I wouldn't consider myself a Python expert.

I see you have tests but would you mind also enumerating the expected behavior for the following scenarios?

performing an async evaluation on a synonymous provider
performing a sync evaluation on an async provider that implements the AbstractProvider

I believe I understand how everything will behave but I'd like to confirm.

Also, could someone with more Python experience please weigh in when you have a moment? FYI, @aepfli @guidobrei @federicobond @jamescarr @lukas-reining @toddbaert

leohoare · 2025-01-27T21:20:21Z

I see you have tests but would you mind also enumerating the expected behavior for the following scenarios?

Do you mean explain the scenarios or update the tests?

performing an async evaluation on a synonymous provider

If async evaluation is not implemented, it will fall back to calling the synchronous function.
I.e. the call will be async but the code itself will be blocking and not truly async.

performing a sync evaluation on an async provider that implements the AbstractProvider

a provider that implements async calls is forced to implement sync functions.
If calls on the AbstractProvider are implemented in the sync function, then the calls will be like client previously functioned.

    def resolve_boolean_details(
        self,
        flag_key: str,
        default_value: bool,
        evaluation_context: Optional[EvaluationContext] = None,
    ) -> FlagResolutionDetails[bool]:
        # do some thing things...
        return FlagResolutionDetails(value=True)

If the provider chooses to only implement async functions and throw an error on the sync functions.
Then the client will throw an error when attempting to resolve values.

        def resolve_boolean_details(
            self,
            flag_key: str,
            default_value: bool,
            evaluation_context: Optional[EvaluationContext] = None,
        ) -> FlagResolutionDetails[bool]:
            raise NotImplementedError("Use the async method")

We're essentially offloading the decision to the provider on how to handle async/sync calls. Implementing the async calls is optional and defaults to sync when not implemented.

Signed-off-by: leohoare <[email protected]>

… imports) Signed-off-by: leohoare <[email protected]>

Missed auto format Signed-off-by: Leo <[email protected]> Signed-off-by: leohoare <[email protected]>

leohoare · 2025-01-27T21:40:55Z

Sorry keep forgetting to sign-off the commits -.-

beeme1mr · 2025-01-27T21:47:11Z

I've approved because I'm good with the approach. Hopefully others with more Python experience can also provide some thoughts.

lukas-reining · 2025-01-28T16:28:54Z

Sorry for the late reply, I have been on vacation. Will have a look in the next 1 or 2 days :)

ChihweiLHBird

This looks good to me! I think we should mention the fallback mechanism in the documentation to avoid confusion. Users might expect asynchronous execution when calling those async functions, but they actually get synchronous function execution.

Signed-off-by: leohoare <[email protected]>

…terhooks and update readme with async doco Signed-off-by: leohoare <[email protected]>

leohoare · 2025-02-02T09:57:14Z

I've updated the readme to include the suggestion @ChihweiLHBird, as well a general usage code block.

@chrfwow due to the refactoring required in this PR, some of your recent merge had to be moved.
Could you please also review this PR (particularly the last two commits)?

README.md

Signed-off-by: leohoare <[email protected]>

chrfwow

The changes of my latest additions seem fine so far, but I have a few other questions

chrfwow · 2025-02-03T07:18:04Z

openfeature/client.py

@@ -295,54 +461,224 @@ def evaluate_flag_details(  # noqa: PLR0915
        reversed_merged_hooks = merged_hooks[:]
        reversed_merged_hooks.reverse()

+        return provider, hook_context, hook_hints, merged_hooks, reversed_merged_hooks
+
+    def _assert_provider_status(


From the function name _assert_provider_status I would expect the function to throw an error when the provider is not ready. I would not expect the function to have any side effects like invoking hooks.

How about _validate_provider_status? or do you have any other suggestions?

Wouldn't it be possible to just throw the proper exception (both ProviderNotReadyError and ProviderFatalError are instances of OpenFeatureError, so the exception handling should work)? This function is called inside the try catch block, so the error hooks will also be called this way.
If not, I would go for a name like _handle_provider_not_ready, but I don't like that name either

This code previously wasn't in the try catch. Although with your refactor, we should be able to throw exceptions here now.
I'll look into this today.

Good catch, this simplified the logic a lot.

openfeature/client.py

gruebel

nice work, just added a few comments

openfeature/provider/in_memory_provider.py

openfeature/client.py

beeme1mr · 2025-02-04T14:30:21Z

Greets everyone! I'd like to get this merged by the end of the week if possible. Please leave you feedback ASAP if you have any concerns. Thanks!

@leohoare, thanks for you hard work and patience. It's important that we have consensus when making changes to the public APIs. So changes like this tend to take a while.

lukas-reining

Looks good to me, left one question :)
Thank you very much!

lukas-reining · 2025-02-04T21:11:10Z

README.md

@@ -109,6 +109,7 @@ print("Value: " + str(flag_value))
 | ✅      | [Eventing](#eventing)                                               | React to state changes in the provider or flag management system.                                                                     |
 | ✅      | [Shutdown](#shutdown)                                               | Gracefully clean up a provider during application shutdown.                                                                           |
 | ✅      | [Transaction Context Propagation](#transaction-context-propagation) | Set a specific [evaluation context](/docs/reference/concepts/evaluation-context) for a transaction (e.g. an HTTP request or a thread) |
+| ✅      | [Asynchronous Feature Retrieval](#asynchronous-feature-retrieval)   | Evaluate flags in an asychronous context.                                                                                                 |


Not sure if we should add this here.
For JS we do not consider this as a feature and the feature list generally lists features that are "explicitly specified".
So for consistency I think it would make sense to leave it out or alternatively add it to the JS SDK readme.

@lukas-reining fair call, I'll leave it out.
Just the row in the table or the section Asynchronous Feature Retrieval as well?

I would say only in the table.
Having it in the README can make sense to me :)

Alright, I've removed the row from the table.

Signed-off-by: leohoare <[email protected]>

leohoare force-pushed the feature/refactor_and_switch_to_single_client branch from c003a56 to 4ec15be Compare January 12, 2025 08:49

leohoare changed the title ~~refactor, switch to single client with common code and fallback~~ Feature: Add async functionality to providers Jan 12, 2025

leohoare changed the title ~~Feature: Add async functionality to providers~~ Feat: Add async functionality to providers Jan 12, 2025

leohoare changed the title ~~Feat: Add async functionality to providers~~ feat: Add async functionality to providers Jan 12, 2025

leohoare mentioned this pull request Jan 12, 2025

feat: simplify async functionality to provider #385

Closed

beeme1mr requested review from federicobond, kinyoklion, aepfli, thomaspoignant, toddbaert, gruebel and lukas-reining January 13, 2025 15:29

leohoare force-pushed the feature/refactor_and_switch_to_single_client branch 4 times, most recently from 86c64df to bb9a4e6 Compare January 22, 2025 10:31

leohoare marked this pull request as ready for review January 23, 2025 00:47

leohoare force-pushed the feature/refactor_and_switch_to_single_client branch 2 times, most recently from 5142300 to 5d34cd8 Compare January 23, 2025 05:12

beeme1mr reviewed Jan 24, 2025

View reviewed changes

beeme1mr approved these changes Jan 27, 2025

View reviewed changes

leohoare force-pushed the feature/refactor_and_switch_to_single_client branch from 3db8642 to e51451d Compare January 27, 2025 21:35

leohoare added 2 commits January 28, 2025 08:37

refactor, switch to single client with common code and fallback

991396d

Signed-off-by: leohoare <[email protected]>

add readme, async to in memory provider and a few more tests

7e3f406

Signed-off-by: leohoare <[email protected]>

leohoare and others added 3 commits January 28, 2025 08:37

add test coverage, async providers calling sync calls, async only client

6793fea

Signed-off-by: leohoare <[email protected]>

make green tick✅✅ (python exception message 3.12+ and removing unused…

af395be

… imports) Signed-off-by: leohoare <[email protected]>

Update test_provider_compatibility.py

72d69d5

Missed auto format Signed-off-by: Leo <[email protected]> Signed-off-by: leohoare <[email protected]>

leohoare force-pushed the feature/refactor_and_switch_to_single_client branch from e51451d to 72d69d5 Compare January 27, 2025 21:38

ChihweiLHBird approved these changes Feb 2, 2025

View reviewed changes

leohoare added 2 commits February 2, 2025 20:23

merge main and adapt code to follow 8f2caba

cd20c12

Signed-off-by: leohoare <[email protected]>

ensure flag_evaluation variable is present, add flag_evaluation to af…

a339b2a

…terhooks and update readme with async doco Signed-off-by: leohoare <[email protected]>

beeme1mr reviewed Feb 2, 2025

View reviewed changes

README.md Show resolved Hide resolved

beeme1mr reviewed Feb 2, 2025

View reviewed changes

README.md Outdated Show resolved Hide resolved

leohoare added 2 commits February 3, 2025 11:54

remove extra carraige returns

21ce38e

Signed-off-by: leohoare <[email protected]>

removal trailing whitespace

e7b951e

Signed-off-by: leohoare <[email protected]>

chrfwow suggested changes Feb 3, 2025

View reviewed changes

gruebel reviewed Feb 3, 2025

View reviewed changes

openfeature/provider/in_memory_provider.py Show resolved Hide resolved

openfeature/client.py Show resolved Hide resolved

openfeature/client.py Show resolved Hide resolved

gruebel approved these changes Feb 3, 2025

View reviewed changes

lukas-reining approved these changes Feb 4, 2025

View reviewed changes

leohoare added 2 commits February 5, 2025 10:02

simplify _assert_provider_status, remove row from README

64e363a

Signed-off-by: leohoare <[email protected]>

correct return type for _assert_provider_status

c0ab87e

Signed-off-by: leohoare <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: Add async functionality to providers #413

feat: Add async functionality to providers #413

leohoare commented Jan 12, 2025 •

edited

Loading

codecov bot commented Jan 13, 2025 •

edited

Loading

beeme1mr commented Jan 13, 2025

leohoare commented Jan 22, 2025

beeme1mr commented Jan 23, 2025

leohoare commented Jan 23, 2025

beeme1mr left a comment

leohoare commented Jan 27, 2025

leohoare commented Jan 27, 2025

beeme1mr commented Jan 27, 2025

lukas-reining commented Jan 28, 2025

ChihweiLHBird left a comment

leohoare commented Feb 2, 2025

chrfwow left a comment

chrfwow Feb 3, 2025

leohoare Feb 3, 2025

chrfwow Feb 4, 2025

leohoare Feb 4, 2025

leohoare Feb 4, 2025

gruebel left a comment

beeme1mr commented Feb 4, 2025

lukas-reining left a comment

lukas-reining Feb 4, 2025

leohoare Feb 4, 2025

lukas-reining Feb 4, 2025

lukas-reining Feb 4, 2025

leohoare Feb 4, 2025

feat: Add async functionality to providers #413

Are you sure you want to change the base?

feat: Add async functionality to providers #413

Conversation

leohoare commented Jan 12, 2025 • edited Loading

This PR

Follow-up Tasks & TODOS

codecov bot commented Jan 13, 2025 • edited Loading

Codecov Report

beeme1mr commented Jan 13, 2025

leohoare commented Jan 22, 2025

beeme1mr commented Jan 23, 2025

leohoare commented Jan 23, 2025

beeme1mr left a comment

Choose a reason for hiding this comment

leohoare commented Jan 27, 2025

leohoare commented Jan 27, 2025

beeme1mr commented Jan 27, 2025

lukas-reining commented Jan 28, 2025

ChihweiLHBird left a comment

Choose a reason for hiding this comment

leohoare commented Feb 2, 2025

chrfwow left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gruebel left a comment

Choose a reason for hiding this comment

beeme1mr commented Feb 4, 2025

lukas-reining left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

leohoare commented Jan 12, 2025 •

edited

Loading

codecov bot commented Jan 13, 2025 •

edited

Loading