attached to a different loop means a fixture and its consumer ran on two different collectors' loops — and which loop each one got is decided by two separate settings with two different defaults. Before debugging anything, check whether asyncio_default_fixture_loop_scope is set. If it is unset you do not yet know which loop your fixtures ran on, and pytest-asyncio warns about exactly that.Four signatures, all of which mean the same underlying thing and none of which say so:
\n\nRuntimeError: Task <Task pending name='Task-4' coro=<test_charge()>> got Future\n<Future pending> attached to a different loop\n\nRuntimeError: Event loop is closed\n\nScopeMismatch: You tried to access the 'function' scoped fixture\n'_function_scoped_runner' with a 'session' scoped request object\n\nRuntimeError: There is no current event loop in thread 'MainThread'None of these is a bug in asyncio, and none is fixed by wrapping the call in try/except RuntimeError. They are all the same class of mistake: something was created on one event loop and used or closed on another. The rest of this article is about telling which of the five causes is yours, because the fixes are different and applying the wrong one moves the failure rather than removing it.
The mechanism is stated plainly in pytest-asyncio's concepts page, and it is the only model you need: \"Pytest-asyncio provides one asyncio event loop for each pytest collector.\"
\n\npytest builds a hierarchy of collectors — Session at the root, then Package, Module, Class, and Function — and, as the docs point out, \"the individual levels resemble the possible scopes of a pytest fixture.\" pytest-asyncio hangs one loop off each level. A loop's lifetime is therefore the lifetime of its collector: the Function collector's loop is created and closed around a single test, the Session collector's loop lives for the whole run.
\n\nBy default a test uses the narrowest one. The docs are explicit about both the behaviour and the reason: \"each test runs in the event loop provided by the Function collector, i.e. tests use the loop with the narrowest scope. This gives the highest level of isolation between tests.\"
\n\nSo loop scope is a second axis, separate from fixture caching scope. A fixture can be built once per module and still run on a session loop, or be rebuilt per test and still run on a module loop. Every one of the errors above is that second axis being set by accident.
\n\nMake the axis visible before you touch anything else. Loop identity is a number, and printing it converts \"a different loop\" into two numbers you can compare:
\n\nimport asyncio, logging\n\nLOG = logging.getLogger(__name__)\n\ndef loop_id() -> str:\n try:\n return hex(id(asyncio.get_running_loop()))\n except RuntimeError:\n return \"<no running loop>\"\n\n@pytest_asyncio.fixture(scope=\"session\")\nasync def engine():\n LOG.warning(\"engine created on loop=%s\", loop_id())\n ...\n\nasync def test_charge(engine):\n LOG.warning(\"test running on loop=%s\", loop_id())Run it with -s and read the two lines. If they differ, you have confirmed the class of problem in one run and can go straight to the right cause below.
This is the most common cause and the least obvious, because it is a disagreement between two configuration options that most projects never set.
\n\nFor tests, the reference says asyncio_default_test_loop_scope \"determines the default event loop scope of asynchronous tests. When this configuration option is unset, it defaults to function scope.\"
For fixtures, asyncio_default_fixture_loop_scope \"determines the default event loop scope of asynchronous fixtures. When this configuration option is unset, it defaults to the fixture scope. In future versions of pytest-asyncio, the value will default to function when unset.\"
Read those together. Unset, a scope=\"session\" async fixture takes a session loop, while every test that consumes it takes a function loop. The client, engine or connection pool the fixture built is bound to the session loop; the test awaits it on a per-test loop; you get attached to a different loop on the first await that touches the pool.
Worth knowing: the decorator reference describes the default differently again, stating that for @pytest_asyncio.fixture \"the default event loop scope is function scope.\" Rather than work out which description applies to your installed version, set the option — pytest-asyncio emits a warning when it is unset, and the project has changed the wording of that warning to make the point harder to miss.
[tool.pytest.ini_options]\n# Set both. Unset is not a neutral default; it is a documented pending change.\nasyncio_default_fixture_loop_scope = \"session\"\nasyncio_default_test_loop_scope = \"session\"Discriminating check: run pytest --collect-only 2>&1 | grep -i asyncio. If the unset-option warning appears, this cause is live in your suite whether or not it is the one biting today. Fix it first, because leaving it unset makes every other diagnosis provisional.
Choosing session for both is the usual right answer when your async resources are pools and clients, since those are exactly the things you do not want rebuilt per test. It costs you loop isolation between tests, which matters if a test leaves a task pending — see the debug-mode section for how that surfaces.
When the error names a fixture you never wrote — _function_scoped_runner is the usual one — you have hit a documented constraint rather than a bug.
The decorators reference states it exactly: the loop scope \"can be chosen independently from its caching scope. However, the event loop scope must be larger or the same as the fixture's caching scope. In other words, it's possible to reevaluate an async fixture multiple times within the same event loop, but it's not possible to switch out the running event loop in an async fixture.\"
\n\nSo loop_scope ≥ scope, always. The four documented combinations, which are worth reading as a set because the third and fourth differ only in caching:
import pytest_asyncio\n\n@pytest_asyncio.fixture\nasync def fresh_loop_every_function(): ...\n\n@pytest_asyncio.fixture(loop_scope=\"session\", scope=\"module\")\nasync def session_loop_rebuilt_once_per_module(): ...\n\n@pytest_asyncio.fixture(loop_scope=\"module\", scope=\"module\")\nasync def module_loop_built_once_per_module(): ...\n\n@pytest_asyncio.fixture(loop_scope=\"module\")\nasync def module_loop_rebuilt_every_function(): ...The second is the shape most suites want for a database engine: one loop for the whole run, but a fresh engine per module so a module can be run alone.
\n\nDiscriminating check: read which side of the error message names which scope. 'function' scoped fixture ... with a 'session' scoped request object means a session-scoped thing requested a function-scoped thing — the requester is yours and the requested is usually the plugin's per-function runner. Widen the loop scope on your fixture; do not narrow its caching scope, which is the reflex and which usually just relocates the problem.
This cause produces an error with no mention of loops at all, which is why it costs people an afternoon:
\n\nAttributeError: 'async_generator' object has no attribute 'create_customer'Strict mode is the default, and the concepts page says what that means: \"In strict mode pytest-asyncio will only run tests that have the asyncio marker and will only evaluate async fixtures decorated with @pytest_asyncio.fixture. Test functions and fixtures without these markers and decorators will not be handled by pytest-asyncio.\"
An async fixture written with plain @pytest.fixture is therefore not an async fixture. pytest calls it, gets an async generator object back, and injects that object into your test. Every attribute access on it fails, and the message names your method rather than the plugin.
# Wrong in strict mode: pytest-asyncio never takes ownership of this,\n# so the test receives the generator object rather than the client.\n@pytest.fixture\nasync def api_client():\n async with AsyncClient(base_url=BASE) as client:\n yield client\n\n\n# Right: the decorator is what hands ownership over.\nimport pytest_asyncio\n\n@pytest_asyncio.fixture(loop_scope=\"session\")\nasync def api_client():\n async with AsyncClient(base_url=BASE) as client:\n yield clientThe alternative is auto mode, which \"automatically adds the asyncio marker to all asynchronous test functions\" and \"will also take ownership of all async fixtures, regardless of whether they are decorated with @pytest.fixture or @pytest_asyncio.fixture.\" Pick it if asyncio is the only async library in the repository. Keep strict mode if you also run trio or anyio tests — the docs give that coexistence as the reason strict is the default, since \"pytest plugins need to coexist peacefully in their default configuration.\"
Discriminating check: the type in the error. async_generator or coroutine in an AttributeError or TypeError means ownership, not loops. No loop error will ever name a generator type.
Event loop is closed is the one that appears during teardown, or on the second test rather than the first. The resource was created on a loop that has since been closed, and something is still holding it.
# Wrong. The engine is cached for the session, but with the fixture loop\n# scope unset it was created on whichever loop was running at the time.\n# dispose() then runs during session teardown, after that loop is gone.\n@pytest_asyncio.fixture(scope=\"session\")\nasync def engine():\n engine = create_async_engine(TEST_DATABASE_URL)\n yield engine\n await engine.dispose() # RuntimeError: Event loop is closed# Right. The loop scope is stated, so creation and disposal happen on the\n# same loop, and that loop outlives the fixture that owns the engine.\n@pytest_asyncio.fixture(loop_scope=\"session\", scope=\"session\")\nasync def engine():\n engine = create_async_engine(TEST_DATABASE_URL)\n yield engine\n await engine.dispose()\n\n# Per-test isolation comes from the connection, not from rebuilding the\n# engine — and this fixture is allowed a narrower caching scope because\n# its loop scope is still session.\n@pytest_asyncio.fixture(loop_scope=\"session\")\nasync def db(engine):\n async with engine.connect() as conn:\n transaction = await conn.begin()\n yield AsyncSession(bind=conn)\n await transaction.rollback()Discriminating check: which test fails. If the first test in a module passes and the second fails, the resource is being reused across loops — a caching scope wider than the loop scope. If the failure is only ever in teardown, the create and the close are on different loops. Run one test alone (pytest path::test_one): if it passes and the pair fails, it is reuse; if the single test also fails at teardown, it is disposal.
The last cause is contamination from a test that is not even async. pytest-asyncio's changelog records both symptoms as bugs it had to fix: RuntimeError: There is no current event loop in thread 'MainThread' arising \"when any test unsets the event loop (such as when using asyncio.run and asyncio.Runner)\", and a ResourceWarning: unclosed event loop that \"could occur when a synchronous test called asyncio.run() or otherwise unset the current event loop after pytest-asyncio had run an async test or fixture.\"
Those specific fixes have shipped, so on a current version you may not see them. The underlying practice is still wrong and still produces confusing failures with third-party code that reaches for the current loop:
\n\n# Wrong. asyncio.run() creates a loop, runs the coroutine, closes the\n# loop, and leaves no current loop set. Anything later in the session\n# that expects one is now running in a different world.\ndef test_health_sync():\n assert asyncio.run(check_health()) == \"ok\"\n\n\n# Right. Let pytest-asyncio own the loop.\nasync def test_health():\n assert await check_health() == \"ok\"Discriminating check: ordering. If the failure disappears when you run the failing test alone but reappears in the full file, grep the module for asyncio.run, asyncio.Runner, new_event_loop and set_event_loop. This is the only cause on this list whose reproduction depends on which tests ran before it, which makes it the fastest to confirm and the easiest to miss.
pytest-asyncio exposes asyncio's debug mode as a first-class option: asyncio_debug = true in the config file, or --asyncio-debug on the command line. It \"enables asyncio debug mode for the default event loop used by asynchronous tests and fixtures,\" and is off by default.
What it buys is location. A pending coroutine normally reports only that it happened:
\n\ntest.py:7: RuntimeWarning: coroutine 'test' was never awaitedWith debug mode on, CPython attaches the creation traceback:
\n\ntest.py:7: RuntimeWarning: coroutine 'test' was never awaited\nCoroutine created at (most recent call last)\n File \"../t.py\", line 9, in <module>\n ...\n File \"../t.py\", line 7, in main\n test()Three more behaviours are worth the noise while you are hunting a loop problem. Exceptions set on a Future that nobody awaits are otherwise lost entirely — Python's docs note that in that case \"asyncio would emit a log message when the Future object is garbage collected,\" which is how a background task that failed silently becomes visible. Callbacks taking longer than 100 milliseconds are logged, with loop.slow_callback_duration available to change the threshold. And \"many non-threadsafe asyncio APIs (such as loop.call_soon() and loop.call_at() methods) raise an exception if they are called from a wrong thread\" — which turns a class of silent corruption into an immediate failure.
Pair it with -W default so ResourceWarning is displayed rather than suppressed. Unclosed transports and unclosed loops are ResourceWarnings, and by default you never see them.
pytest --asyncio-debug -W default -s tests/integration/Set both loop-scope options explicitly today, even if nothing is currently failing. Unset is not a stable state — the reference documents the fixture default as changing in a future version, which means an upgrade can move every async fixture in your suite onto a different loop without any change of yours.
\n\nThen add the loop-identity log line to the widest async fixture you own and to one test that consumes it, and run that pair with -s. Two matching hex values is the evidence that the ownership is now what you think it is; that one line, kept in the fixture behind a debug-level logger, is what makes the next occurrence a two-minute diagnosis.
Finally, grep the suite for asyncio.run outside of if __name__ == \"__main__\" blocks. Every hit inside a test is a latent ordering-dependent failure.
It is the right default when your async resources are connection pools and HTTP clients, because those are expensive and loop-bound. The cost is that a test which leaves a task pending now leaks it into every later test rather than having it destroyed with its own loop. If you take session scope, take debug mode with it in CI — unretrieved task exceptions are the failure this trade introduces, and debug mode is what makes them visible.
\n\nThey can, and pytest-asyncio advises against it: \"it's highly recommended for neighboring tests to use the same event loop scope. For example, all tests in a class or module should use the same scope. Assigning neighboring tests to different event loop scopes is discouraged as it can make test code hard to follow.\" In practice, mixing them within a module is also how you end up with a fixture that works for the first test and not the second, so treat the module as the unit at which loop scope is decided.
\n\nBecause a loop belongs to a process. Each xdist worker is its own process with its own collectors and therefore its own loops, so anything shared between workers — a connection pool built in a plugin, a client cached in a module-level global at import time — is being used from a loop that did not create it. The fix is not loop configuration; it is making the resource per-worker. Objects created at import time are the ones to look at first, since import happens before any loop exists.
\n\nNo, and it is worth being blunt because it is a common suggestion. attached to a different loop is raised before your coroutine does any work, so catching it does not retry anything — it converts a loud ownership bug into a test that passes without having tested. The only legitimate use of except RuntimeError near a loop is the one in the diagnostic helper earlier in this article, where get_running_loop() is called deliberately outside a loop to report that fact.
Own them explicitly: keep a reference to every task it starts, and cancel and await them before it yields control back. A task holds a reference to its loop, so a task still pending when the loop closes is the direct cause of both Event loop is closed during teardown and unretrieved-exception log lines afterwards. Debug mode is how you find the ones you did not know about — the garbage-collection log message for an unawaited Future exception is often the first evidence that a fixture started something it never finished.
attached to a different loop.@pytest_asyncio.fixture are evaluated and undecorated ones \"will not be handled by pytest-asyncio\"; that auto mode takes ownership of all async fixtures either way; and that strict is default so plugins \"coexist peacefully in their default configuration\".--asyncio-debug flag enable asyncio debug mode \"for the default event loop used by asynchronous tests and fixtures\", and that it is disabled by default.loop.call_soon() raise when called from the wrong thread, slow I/O selector time is logged, and \"callbacks taking longer than 100 milliseconds are logged\" with loop.slow_callback_duration as the threshold. Also the advice to display ResourceWarning via -W default.RuntimeWarning: coroutine 'test' was never awaited, and that debug mode additionally reports \"Coroutine created at (most recent call last)\" with the creation traceback.Future.set_exception() is called on a Future that is never awaited, \"the exception would never be propagated to the user code\" and asyncio \"would emit a log message when the Future object is garbage collected\".pytestmark can apply it to a whole module, and that loop_scope on the marker takes function, class, module, package or session.asyncio_default_fixture_loop_scope is unset (and its wording was revised for readability); the recorded RuntimeError: There is no current event loop in thread 'MainThread' arising when a test unsets the loop \"such as when using asyncio.run and asyncio.Runner\"; and the ResourceWarning: unclosed event loop from a synchronous test calling asyncio.run() after pytest-asyncio had run an async test or fixture.