"Event loop is closed" error in _provide_clean_event_loop()
#548
Comments
|
Thanks for providing the logs and the link to the project sources. Unfortunately, I cannot reproduce the error locally. After building deltachat-rpc-server I was able to run From the top of my head there are two things you can do. If the error occurs with Python 3.7 only, you may consider testing with Python 3.8. Major parts of asyncio have been rewritten in Python 3.8 and Python 3.7 will reach end-of-life in roughly 6 weeks. Alternatively, you can try to isolate the error in a simpler example. Your setup is quite complex and involves building executables and creating online accounts to run the tests. If you can create a minimal example that reproduces the issue, chances are much higher that we can help you. |
seifertm
added
the
needsinfo
|
I also cannot reproduce it locally, it happens randomly on GitHub Actions. Maybe GitHub runner pauses the processes or otherwise triggers race conditions that do not happen when you run the tests on a dev machine. I mostly hoped that something can be figured out of the backtrace. This seems to be somehow related to having a subprocess, and deltachat-rpc-client Python library indeed starts a deltachat-rpc-server Rust binary as a subprocess. The backtrace in a better form:
So attach_loop of the child watcher is called here: Then new loop is set and Apparently this race condition happens and a child indeed terminated but was not handled while previous loop was set. So we are handling it now, right after switching to a new loop. A child handler callback is called, which is actually a |
|
There is indeed something different about how setting event loop is handled in Python 3.7. I have created an example: This produces a warning "RuntimeWarning: A loop is being detached from a child watcher with pending handlers" with Python 3.7, but not with Python 3.8. The warning about loop being detached is produced when the loop is set to So somehow with Python 3.7 One difference I see comparing 3.8.0 to 3.7.16 is that default child watcher is changed to As for pytest-asyncio, maybe it is possible to somehow avoid setting global/thread-local variables and make it less stateful to avoid such problems on the architectural level? Just a thought, I did not even read the whole |
|
I am going to drop support for Python 3.7 at deltachat/deltachat-core-rust#4410 If getting rid of |
seifertm
removed
the
needsinfo
|
Thanks for the thorough investigation and summary! This sounds like a duplicate of #114. The issue was closed a couple of months ago, because it's unlikely that anyone is going to backport the asyncio.ThreadedChildWatcher to Python 3.7.
Right now, pytest-asyncio uses get_event_loop() during setup of the event_loop fixture. Unfortunately, get_event_loop creates a new loop when no loop has been set or returns the old loop when set_event_loop was called. The goal is to get rid of both get_event_loop and set_event_loop calls, especially due to recent changes to get_event_loop. [0] The problem is that pytest-asyncio currently uses _get_event_loop to clean up unclosed event loops for the users. Technically, this is "bad loop hygene", but we cannot just remove the functionality without warning. Therefore, pytest-asyncio emits a DeprecationWarning since v0.21 when it closes an event loop for the user. The plan is to remove that functionality in future versions of pytest-asyncio. I'll close this as a duplicate of #114. Feel free to continue the discussion, though. |
The error sometimes happens during the test teardown.
Here is an example of a failure:
https://github.com/deltachat/deltachat-core-rust/actions/runs/5022838715/jobs/9006825246
Slightly cleaned up (removed
git cloneprogress) log:Failure log
The text was updated successfully, but these errors were encountered: