Open carlosjourdan opened 7 months ago
hi @carlosjourdan - thanks for the issue! there are a couple things about this example code that you could try updating
get_client()
to get a client instead of using the context's client. you should have no client lifetime issues like the one you seem to be hitting hereasync
, since you're already using asyncio.sleep
and async
client methods. the run_sync
is adding complexity that may not be warranted hereThanks @zzstoatzz.
To give some more context, I'm building a library that will be used by researchers at a financial institution. All their code is sync, hence the need to avoid exposing any async functions. I introduced the asyncio.sleep
in the example just to show that run_sync
works fine with it, but fails with the Prefect client.
Following your suggestion to use get_client()
, I was able to make the code work, but I still see some things that could be addressed from this issue:
RunContext.client
attribute to call the backend. In my actual code, I was already calling get_run_context()
to access some other information, so it only seemed natural to use the client
attribute contained in itsync_client
property that would seem ideal for my use case, but the returned sync client exposes far less methods than its async counterpartget client()
, if I executed several api calls, each one wrapped on its own run_sync
call, I'd still get some Event loop is closed
errors. The solution was to create one single async method that calls get_client()
, awaits each api call, and then wrap that method with a single run_sync
call.
First check
Bug summary
When tying to run prefect client async methods from a sync context on kubernetes, I get a "RuntimeError: is bound to a different event loop" error. I've tried using
prefect.utilities.asyncutils.run_sync
,asyncio.run
andasyncio.get_event_loop().run_util_complete
.The code works fine locally, and calling a simple async on the k8s deployment also works. I'm only able to reproduce the error in the k8s deployment with the prefect.client methods.
Reproduction
The image basically builds from
python:3.11-buster
, installs some packages and copies the source files to the/source
dir.This is the result of a pip freeze:
Versions
Additional context
No response