Michael Seifert

> Thanks for the response! > > Honestly, up until I discovered this bug, I just assumed that pytest-asyncio was a simple wrapper around `asyncio.run`. Now I understand the internals...

This issue has been addressed by the migration to `asyncio.Runner`. @CGamesPlay Can you confirm that the issue is resolved in the pre-release version `pytest-asyncio==1.1.0a1`?

I can definitely see that it can be desirable to fail a test when the code under test has pending tasks. I also understand the issue of warnings of pending...

No longer reproducibel in v1.0.0a1 and should be fixed as part of the v1.0.0 release.

Thanks for bringing this to attention! #205 proposes to have a default loop exception handler that re-raises exceptions in background tasks. @schlamar would this be sufficient for your use case...

That makes sense. The event loop policy support is not in a good state, unfortunately. I think this is closely related to #796.

I'm also linking #1032 which argues that this kind of customization should be possible through the _async_ marker. For example: `@pytest.mark.asyncio(policy=…)`. It's also worth mentioning that upstream is deprecating the...

There's a [draft PR](#1164) that aims to provide a `loop_factory` argument to `pytest.mark.asyncio` and `pytest_asyncio.fixture`, in order to control the loop factory/policy used for tests and fixtures. However, it turns...

> Can you please clarify what is the intended outcome in this code below? Should it work? The [pytest_asyncio.fixture](https://pytest-asyncio.readthedocs.io/en/v1.0.0/reference/decorators/index.html#decorators) decorator has two different kinds of scopes: pytest's caching scope which...

Thanks for reporting this! Could this be a regression of https://github.com/pytest-dev/pytest-asyncio/pull/1045?