pytest-anyio and crashed background task in taskgroup fixture #805
Comments
|
How did you run the first snippet with trio as backend? I put it in a single test module, and ran pytest with the module as argument plus |
ah hmm, for snippet 1 I only get it when I run both asyncio&trio, so I suppose it's something about the fixture not being torn down & re-set up properly? I tested it just now with pytest-random-order and if running trio 1st and asyncio 2nd I get a similar error: Not sure how to help you repro the 2nd snippet, I can reliably re-repro it in new venv's. |
|
I noticed that you had a global |
Ah thanks. Making it a fixture resolved it when using import anyio
import pytest
@pytest.fixture
def my_event():
return anyio.Event()
async def die_soon(my_event, task_status):
print("entering die_soon")
task_status.started()
await my_event.wait()
print("crashing")
raise RuntimeError('OOPS')
@pytest.fixture
async def my_simple_fixture(my_event):
async with anyio.create_task_group() as tg:
await tg.start(die_soon, my_event)
print("yielding")
yield
print("continuing")
@pytest.mark.anyio
async def test_try(my_simple_fixture, my_event):
print("in test")
my_event.set()
print("end of test")I'm now getting |
|
This randomness is due to Trio's non-deterministic scheduling. If you know how to turn that off, please let me know! It's supremely annoying when running tests. |
sorry, with |
Well, that's easy. Also, in |
|
I think I'll ask around about this particular variable and its future. |
|
On second look a better solution is to call Trio should probably export a way to explicitly set that seed. I'd recommend to submit a PR. |
|
It's not just the random scheduling I'd like to tackle, but I'd really like to make trio schedule tasks in the FIFO order. Does |
|
No. If you want that, you need to monkeypatch |
|
I think this and #614 should probably be fixed together as part of a larger overhaul of the pytest plugin. |
|
I started experimenting, but I'm not sure what the desired end result is with code like this: class TestFailingFixtureTaskGroup:
@pytest.fixture
async def failing_task(self) -> AsyncGenerator[Event]:
event = Event()
async def die_soon(task_status: TaskStatus[None]) -> NoReturn:
task_status.started()
await event.wait()
raise RuntimeError("OOPS")
async with create_task_group() as tg:
await tg.start(die_soon)
yield event
async def test_tg_crash(self, failing_task: Event) -> None:
failing_task.set()
await checkpoint()Is the expectation that the teardown phase errors with an exception group containing the |
|
I think we should visualize the above test and fixture like this: async def test_tg_crash() -> None:
event = Event()
async def die_soon(task_status: TaskStatus[None]) -> NoReturn:
task_status.started()
await event.wait()
raise RuntimeError("OOPS")
async with create_task_group() as tg:
await tg.start(die_soon)
event.set()
await checkpoint()What do we want to happen when a task group task is cancelled? Since everything runs in the single "runner" task, a failing task group will cause that task to be cancelled. If, on the other hand, we run asyncgen fixtures in separate tasks, they won't be able to set contextvars for the test and the other fixtures. |
I'm not sure if it matters a ton, since teardown error will cause the pytest run to fail & you can see which test caused it. Maybe a bit conceptually nicer to have it as a teardown error |
What's the downsides of cancelling the runner task? |
"Confusion" is the first answer that comes to mind. The same thing that prompted this issue. I at least would be confused about a Also, what will happen to task groups and cancel scopes created in other async fixtures, if one of them cancels the runner task? I haven't really given it much thought until now. |
|
I think what I'm trying to say we should try to accomplish here:
|
Things to check first
I have searched the existing issues and didn't find my bug already reported there
I have checked that my bug is still present in the latest release
AnyIO version
4.6.0
Python version
3.12.4
What happened?
I'm encountering several weird things, where it will either hang in weird places or crash.
This is from trying to rewrite pytest-trio and encountering the test that was added after python-trio/pytest-trio#77 in python-trio/pytest-trio#83
How can we reproduce the bug?
Running this with trio as the backend gives:
if I remove the decorator and directly run
anyio.run(test_try, backend="trio")it correctly gives a group with our "OOPS"RuntimeError, same if running anyio-pytest with asyncio as backend.2
This gives a teardown error and a messy traceback
Error:
3
but if we make
anyio_backendreturn"trio"we instead get a hang. KeyboardInterrupt traceback ends withThe text was updated successfully, but these errors were encountered: