dabla commented on PR #73560: URL: https://github.com/apache/airflow/pull/73560#issuecomment-5831475640
Fair points on both counts, thanks. The PR is reworked in 11f51776a6 and the title and description are updated to match. On `asyncio.run()`: it would be enough for `BaseAsyncOperator.execute` on its own, since that runs one coroutine to completion. The reason the helper exists is that it hands out a loop that outlives a single coroutine. The iterable operator (the follow-up that will build on this) drives one loop through several `run_until_complete()` calls, pausing between batches of sub-tasks, and `asyncio.run()` cannot do that: it creates a loop, runs one coroutine and closes it, so nothing survives between calls. I had tried `asyncio.run()` there earlier and that is why it "didn't work". That is exactly what `asyncio.Runner` is for, so `event_loop()` now owns its loop through a `Runner`: `runner.get_loop()` is what gets yielded, and on exit `Runner` cancels leftover tasks and shuts down async generators and the default executor, which the old helper never did. Nothing touches `asyncio.get_event_loop()` or the policy API any more. The one wrinkle is Python 3.10, which has no `asyncio.Runner`, so a small fallback replicates `Runner.close()` until 3.10 support is dropped; the tests run every case against both paths. The previous "reuse a running loop" branch is gone too. It never actually worked for the callers, since `run_until_complete()` on a running loop raises, so entering the helper from a running loop is now refused up front with a clear error. --- Drafted-by: Claude Code (Fable 5.1); reviewed by @dabla before posting -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
