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 how 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).
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). |
| @@ -49,6 +49,16 @@ | |||
| PytestPluginManager, | |||
| ) | |||
|
|
|||
| _seen_markers: set[int] = set() | |||
There was a problem hiding this comment.
I assume this code is intended to suppress duplicate warnings about keyword arguments in the asyncio marker. This should no longer be needed, because it has been addressed in 8585040.
| ) | ||
| ) | ||
|
|
||
| _SCOPE_TO_CONTEXTVAR = { |
There was a problem hiding this comment.
The current way of handling contextvars with copying them and restoring them was introduced before switching to asyncio.Runner, if I remember correctly.
My understanding is that asyncio.Runner holds a default context along with its loop. We already have one Runner per loop scope. Do you think there's any way we can utilize the Runner's default context rather than storing contexts per scope externally?
This is just something to think about. If it's not possible or it would take a lot more work, we can start with this solution as well.
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.