Follow up to #175, this PR refactors the dispatch-py internals to use asyncio across the board, and only convert between blocking and async modes at interface boundaries.
Overall, this PR does not modify the public API much, but mostly enables to key changes:
it creates a path forward to enable applications to write tests for dispatch functions
it defines a model for waiting on dispatched function results
(these were previously discussed in part 2)
Waiting on dispatched function results
I have added a temporary disaptch.sdk.v1.DispatchService/Wait endpoint -- which is very much experimental at this point and only used in tests -- to allow retrieving the result of dispatched function calls. Along with this change, the SDK is now detecting whether a dispatch function is called (and awaited) from an external client or within the a dispatch execution context. When the former is true, the /Wait endpoint is used to wait for the result of the function call.
I want to emphasize that it's still very much experimental, I want to make sure the model works well end-to-end before committing to an API in https://github.com/dispatchrun/dispatch-proto.
Testing dispatch functions
This PR does not yet deliver on this front, but it makes great progress by adding a generic dispatch.test.TestCase test suite that is used to exercise testing of all integrations with FastAPI, Flask, aiohttp, http.server, etc...
One blocker to finishing this work is the inability to pickle cell objects, which are implicitly generated by Python when local variables are referenced from multiple scopes, and happens in constructs like the following:
(echo exists in the local scopes of test_call_nested_function_with_result and echo2)
These blockers prevent finishing the rewrite of tests in test_fastapi.py::TestCoroutine into dispatch.test.TestCase, which also prevents removing the grpcio and httpx dependencies, and deleting all the gRPC codegen.
Follow up to #175, this PR refactors the dispatch-py internals to use asyncio across the board, and only convert between blocking and async modes at interface boundaries.
Overall, this PR does not modify the public API much, but mostly enables to key changes:
Waiting on dispatched function results
I have added a temporary
disaptch.sdk.v1.DispatchService/Wait
endpoint -- which is very much experimental at this point and only used in tests -- to allow retrieving the result of dispatched function calls. Along with this change, the SDK is now detecting whether a dispatch function is called (and awaited) from an external client or within the a dispatch execution context. When the former is true, the/Wait
endpoint is used to wait for the result of the function call.I want to emphasize that it's still very much experimental, I want to make sure the model works well end-to-end before committing to an API in https://github.com/dispatchrun/dispatch-proto.
Testing dispatch functions
This PR does not yet deliver on this front, but it makes great progress by adding a generic
dispatch.test.TestCase
test suite that is used to exercise testing of all integrations with FastAPI, Flask, aiohttp, http.server, etc...One blocker to finishing this work is the inability to pickle cell objects, which are implicitly generated by Python when local variables are referenced from multiple scopes, and happens in constructs like the following:
(
echo
exists in the local scopes oftest_call_nested_function_with_result
andecho2
)These blockers prevent finishing the rewrite of tests in
test_fastapi.py::TestCoroutine
intodispatch.test.TestCase
, which also prevents removing thegrpcio
andhttpx
dependencies, and deleting all the gRPC codegen.