Fix error when a shared event loop is unset #1180
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1180 +/- ##
==========================================
- Coverage 88.91% 88.47% -0.44%
==========================================
Files 2 2
Lines 406 434 +28
Branches 44 46 +2
==========================================
+ Hits 361 384 +23
- Misses 35 39 +4
- Partials 10 11 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
tjkuson
force-pushed
the
mainthread-fix
branch
3 times, most recently
from
5ff08a0 to
bb8628a
Compare
pytest_asyncio/plugin.py
Outdated
| _loop = _get_event_loop_no_warn() | ||
| except RuntimeError: | ||
| # Handle situation where asyncio.set_event_loop(None) removes shared loops. | ||
| _reinstate_event_loop_on_main_thread() |
There was a problem hiding this comment.
The function _get_event_loop_no_warn is a helper that suppresses a call to get_event_loop, which is effectively deprecated in favor of get_running_loop. This deprecation was one of the drivers for removing the event_loop fixture, which relied on this functionality.
The fact that wrap_in_sync still uses this is unfortunate and I hope to rectify this in #1203.
The point I'm trying to make is that wrap_in_sync seems to be the wrong place to reinstate the loop, because it would mean doubling down on the get_event_loop use.
There was a problem hiding this comment.
Hm, I think I follow. #1203 looks promising, and I'll think about I'd rebase this fix on your PR! In the meantime, I've pushed my revision of the patch to reinstate the specific event loops with they are unset to resolve your concern mentioned the original issue (#1177 (comment)) (which, admittedly, doesn't address this new comment).
pytest_asyncio/plugin.py
Outdated
| @@ -602,6 +603,12 @@ def _set_event_loop(loop: AbstractEventLoop | None) -> None: | |||
| asyncio.set_event_loop(loop) | |||
|
|
|||
|
|
|||
| def _reinstate_event_loop_on_main_thread() -> None: | |||
| if threading.current_thread() is threading.main_thread(): | |||
There was a problem hiding this comment.
My understanding is that pytest doesn't support multi-threading. It doesn't hurt to have this check, but I wonder if you had a specific use case in mind that I'm missing. Is there? :)
There was a problem hiding this comment.
I've removed the check. It was only there as it was needed in the helper function I used in the code under test to temporarily resolve this issue (which did happen to use multi-threading).
tjkuson
force-pushed
the
mainthread-fix
branch
3 times, most recently
from
644bc9f to
e9b9fb9
Compare
tjkuson
force-pushed
the
mainthread-fix
branch
from
e9b9fb9 to
ac9e0d6
Compare
|
@seifertm I've pushed the patch that satisfies the edge-case you mentioned (though the PR is still quite proof-of-concept). |
Automatically reinstates the event loop on the main thread when needed.
The coverage report suggests the patch is uncovered, but I think this is due to limitations of measuring coverage across processes.
Fixes #1177
Note: this is a work-in-progress proposal based on my understanding of the issue. If the maintainers prefer a different approach or consider the issue invalid, I’m happy to adjust or close this PR.