feat: Add async functionality to providers

[leohoare]

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]

Codecov Report

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

Project coverage is 97.71%. Comparing base (154d834) to head (6cef56b).
Report is 1 commits behind head on main.

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.71% +0.15% 
==========================================
Files 31 32 +1 Lines 1393 1621 +228 ==========================================
+ Hits 1359 1584 +225 - Misses 34 37 +3 

Flag	Coverage Δ
unittests	97.71% <97.77%> (+0.15%)	⬆️

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]

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]

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]

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]

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]

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.

[leohoare]

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

[beeme1mr]

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

[lukas-reining]

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.

[leohoare]

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)?

[chrfwow]

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

[gruebel]

nice work, just added a few comments

[beeme1mr]

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!

[beeme1mr]

I'll merge this PR tomorrow unless someone objects.