New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Breaking change in 0.23.* #706
Comments
I confirm, we use similar setup with 2 session level fixtures (one to redefine event loop, another for our own purposes), tests don't work anymore, complain either about "The future belongs to a different loop than the one specified as the loop argument" or "Event loop is closed". |
The version 0.23.0 changelog is already mentioning the breaking change: https://github.com/pytest-dev/pytest-asyncio/releases/tag/v0.23.0 I went through the same, the new way to do it can be seen in this PR https://github.com/pytest-dev/pytest-asyncio/pull/662/files |
It says "This release is backwards-compatible with v0.21. Changes are non-breaking, unless you upgrade from v0.22." |
@albertferras-vrf the changelog mentions asyncio_event_loop mark removal, I think it is only about upgrading from 0.22. |
You are right, I forgot about that part |
That was the original intention, yes. I can reproduce the difference between v0.21.1 and v0.23 and I agree that this is a breaking change (by accident). With regards to the migration and as a workaround: The fundamental idea of v0.23 is that each pytest scope (session, package, module, class, and function) provides a separate event loop. You can decide for each test in which loop they run via the new @tkukushkin In your specific example you want to run the test in the same loop as the fixture. The @pytest.mark.asyncio(scope="session")
async def test_something(some_async_fixture):
assert asyncio.get_running_loop() is some_async_fixture See also the part about asyncio event loops in the Concepts section of the docs. @redtomato74 I'd like to hear more about your use case for two different event loops. I suggest you open a separate issue for this. |
@seifertm I'd like to have only one loop for all fixtures and tests, without additional decorators to all tests and fixtures. We have thousands of tests in hundreds of services where all tests and fixtures share one loop and it is crucial for them. Is there any workaround to emulate the old behaviour? This way https://pytest-asyncio.readthedocs.io/en/v0.23.2/how-to-guides/run_session_tests_in_same_loop.html does not consider fixtures at all( |
The linked how-to is supposed to make it easy to add the
I don't think this use case was considered during the development of v0.22 and v0.23. Can you explain why you need all tests and fixtures to run the same loop? Why
Fixtures in v0.23 generally behave like tests and choose the event loop of the fixture scope. That means if a fixture has I cannot think of a workaround to switch to the old behaviour at the moment. I suggest pinning pytest-asyncio to <0.23 until this issue is fixed. |
Sorry, but I don't understand, I have not only session scoped fixtures but also module scoped fixtures, and they should use the same event loop as session scoped fixtures. Could you please describe how to achieve it?
We write blackbox tests for microservices using pytest and pytest-asyncio. Some session scoped fixtures for example create database connection pool, which all tests can use to check database state. Another session scoped fixture in background monitors logs of subprocesses (instances of application, that we test) and captures these logs to some list, which tests can check. These subprocesses can be started by any fixture and test as async context manager. And obviously, subprocess (asyncio.subprocess) should be started with the same loop as fixture that captures logs from it. And we have way more such examples. |
Thanks for the explanation!
This is what I meant when I said your use case hasn't been considered in the development. There's currently no way to control the event loop used by a fixture independently from the fixture scope. The v0.23 release will not work for your test suite. I suggest that you downgrade to v0.21.1. I'll think of a way to control the fixture scope independently of the event loop scope. |
Yes, we have already downgraded to 0.21.1. I don't think it's gonna be a problem for us for a long time (at least until Python 3.13).
Thank you! Looking forward to the news. |
After upgrade to v 0.23 error in teardown: @pytest.fixture
def server():
from main import _create_fastapy_server
app = _create_fastapy_server()
return app
@pytest_asyncio.fixture
async def client_async(server):
app = server
async with (
app.router.lifespan_context(app),
AsyncClient(app=app, base_url="http://testserver") as client
):
yield client
@pytest.mark.asyncio
async def test_server(client_async):
"""Start - Stop""" Output:
|
@seifertm while I deeply appreciate your work, which is crucial for all python and pytest users dealing with async tests, I don't understand why you had to change the way the event loop is set up: the previous way worked just fine. Please consider restoring the previous behaviour. As for use cases, a few people provided their setups and needs in #657 (and this was my comment) |
@ffissore Thanks for the kind words and for being so upfront. I'm generally open to restoring the previous behavior, if the existing problems with it can be solved in another way. Before I give a more extensive answer: Do you take an issue with the bugs and the incompatibilities that were (involuntatrily) introduced in v0.23? Or do you think the new approach is generally flawed? |
I did not follow exactly the issue, but I wanted to mention that 0.23 broke all our pipelines at work with some strange errors and the same with one of the open source project I maintain: https://github.com/FreeOpcUa/opcua-asyncio . The solution so far has been to revert to 0.21 everywhere |
I'm afraid I'm not in a position to judge the approach: I don't know enough about the previous design and the desired long-term design. IMHO the best solution is the one that makes the end developer write as little code as possible, and only code that is strictly related to what the dev wants to do. |
It was good enough but a terrible DX honestly. It took me quite a while to figure out the first time I've seen this problem (and thought it was a bug or very bad design). If the goal here is that we don't need these five lines anymore, I'm all in and will just pin my dependency until we update our code. Let's not revert to something ugly if the new approach is better. Also, the semantic versioning meaning of 0.* versions is that they can introduce breaking changes anytime. If you don't want to hit this kind of breaking changes in the first place, just pin your dependencies... |
I think the real problem is that the migration process is not clear. I would have expected that removing the Here is a minimal reproducible example (with GitHub CI!) of a real world application that I can't migrate to 0.23 so far: https://github.com/ramnes/pytest-asyncio-706 @seifertm Any hint on how something like this should be migrated? (PR welcome on that repository.) If it's not possible to migrate, then this would be the real issue: it wouldn't be a breaking change but a loss of functionality. Otherwise we'll probably have a few bits to add to the documentation here. :) |
Version 0.23 was accidentally a breaking change: pytest-dev/pytest-asyncio#706
…ks our existing tests(pytest-dev/pytest-asyncio#706)
We also needed to downgrade to 0.21.1 to make our project work. Waiting for a new update. Thanks! |
Prevents issue reported here and revert is the suggested way: pytest-dev/pytest-asyncio#706 Tests in this repository are not affected at the moment because event loops are used only in function scope fixtures but this prevents possible confusion in the future when that would not be the case.
The functional tests requiered some changes, they were done strangely and I'm not sure why they worked before. I think it's maybe due [1], but I did not have time to investigate more. --- [1]: pytest-dev/pytest-asyncio#706
* Set controller channel to 3.4 in CI The functional tests requiered some changes, they were done strangely and I'm not sure why they worked before. I think it's maybe due [1], but I did not have time to investigate more. --- [1]: pytest-dev/pytest-asyncio#706 * tmp fix until [1] is not resulved --- [1]: canonical/charmcraft#1640 * drop bootstack-actions for func tests * define concurrency in CI * dropping tmp usage of 5.20/stable for LXD * Switch back to bootstack-actions
This unblocks all users stuck with 0.21.1 due to pytest-dev#706
I was afraid this day would come. Thanks for keeping 0.21.1 alive. |
We cannot use pytest-async 0.23 because of pytest-dev/pytest-asyncio#706 We need to use pytest-async 0.23 if we use pytest 8.2 because of pytest-dev/pytest#12269 This may be fixed bt this backport of the fix in pytest-async 0.23: pytest-dev/pytest-asyncio#823
This unblocks all users stuck with 0.21.1 due to #706
|
Epic-quick fix. Many thanks @ffissore . |
We cannot use pytest-async 0.23 because of pytest-dev/pytest-asyncio#706 We need to use pytest-async 0.23 if we use pytest 8.2 because of pytest-dev/pytest#12269 This may be fixed bt this backport of the fix in pytest-async 0.23: pytest-dev/pytest-asyncio#823 Test MacOs using Python 3.8 becuase GHA no longer providing 3.7 on that platform
Hello! Something has been broken with the latest pytest-asyncio releases.
Consider such code:
pytest.ini:
This test passes with pytest-asyncio 0.21.1 but fails with 0.23.0. I am not sure if it's ok, but if it is, IMHO it is breaking change.
The text was updated successfully, but these errors were encountered: