Added async workflow client implementation, leveraging new durabletask.aio.client implementation

[passuied]

Description

Added async workflow client implementation, leveraging new durabletask.aio.client implementation

Issue reference

#834

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• Extended the documentation (examples/workflows/simple_aio.py)

[codecov]

Codecov Report

❌ Patch coverage is 94.39252% with 18 lines in your changes missing coverage. Please review.
✅ Project coverage is 87.49%. Comparing base (bffb749) to head (75f3e7c).
⚠️ Report is 48 commits behind head on main.

Files with missing lines	Patch %	Lines
...workflow/dapr/ext/workflow/aio/workflow_runtime.py	80.00%	11 Missing ⚠️
...flow/dapr/ext/workflow/aio/dapr_workflow_client.py	93.33%	4 Missing ⚠️
...pr-ext-workflow/tests/aio/test_workflow_runtime.py	98.30%	2 Missing ⚠️
...apr-ext-workflow/tests/aio/test_workflow_client.py	98.82%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #861      +/-   ##
==========================================
+ Coverage   86.63%   87.49%   +0.86%     
==========================================
  Files          84       98      +14     
  Lines        4473     6484    +2011     
==========================================
+ Hits         3875     5673    +1798     
- Misses        598      811     +213     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[acroca]

@passuied I think this other PR covers this same thing, and is a bit more complete because it also have async context, but it's WIP as it has lots of lint changes that are now applied to main. I'll ask for a cleanup. Can you have a look at that PR and confirm it'd work for you after the cleaning? focus on the ext/dapr-ext-workflow changes :)

[filintod]

@acroca actually this is a bit different, as this tackles the client initiating actions against a workflow(schedule workflow, signal events), instead of the internals of the workflow that my PR tackles. He did the PR in durabletask that complements this dapr/durabletask-python#17. The PRs his/mine are complementary and not overlapping

[acroca]

Looks good, but I'd follow the same pattern as the DaprClient and not have a suffix Async for the async version.

[acroca]

@passuied Can you add an example to examples/workflow that uses this new client? Maybe something like https://github.com/dapr/python-sdk/blob/main/examples/workflow/simple.py but async.
Sorry for adding new items to the review, but I didn't think about it when I reviewed yesterday 🤦

[acroca]

LGTM, but tests are failing, and copyright headers need to be fixed :)

[akotsarelation]

1. Does this mean that if the main_event_loop was not provided in the constructor, we'll silently treat all activities as synchronous? If this is the case, should we make main_event_loop required? Otherwise, it seems to be defeating the purpose. Or am I missing something?
2. Isn't it supposed to call fn() instead of returning the function itself?

[akotsarelation]

Minor - consider storing the workflow.__dict__['_dapr_alternate_name'] / workflow.__name__ in a variable and avoiding code duplication around calling self.__obj.schedule_new_orchestration

[akotsarelation]

I'm not sure if wrapping the sync runtime is the best course of action here. Instead, it should be natively supported by durabletask it looks like there's been a lot of work, including async support done there. Are you sure it's not already a resolved problem?

[passuied]

@akotsarelation I agree that when I look at @filintod's PR, I'm inclined to wait for his work to be complete so we can replace the whole WorkflowRuntime with his full async implementation...
It wasn't so apparent until I worked on the example @acroca and I had to override WorkflowRuntime (but not in an ideal way as I still need the work from that PR)... While the current solution works it does mix sync and async and comes with performance downsides... If this PR is coming soon, I'm inclined to not publish this one and instead wait for the full blown solution....

[filintod]

I guess the issue is that you were changing not only the client side (dapr_workflow_client) but also the workflowruntime, that yeah you would need something like what I am doing. Was that needed here? as your durabletask PR only dealt with the client side (schedule workflow, etc) and why I said this PR and the durabletask were complementary but not if mixing workflow runtime too.