Closed antonyc closed 2 years ago
I suspect that your problem is that the timeout occurs in the setup and not in the call, and this is why pytest is not adding the rep_call
attribute because call
just never happened. You can fix this by being more defensive and not always expecting the attribute to be present, e.g. getattr(request.node, 'rep_call')
or so. If you want to detect the failure of setup maybe there's a similar attribute for setup to inspect?
Yeah, sure, that was the solution I used to escape the tracebacks in logs, thank you.
But, I would like to know, if there is a programmatic way to catch this Timeout for example, if one has the ability to catch SoftTimeLimitExceeded
in Celery (sorry, if I mention the code you haven't seen yet):
https://docs.celeryq.dev/en/stable/userguide/workers.html#time-limits
That would be a clearer way to my mind: just catch exceptions and not perform any assumption about attribute existence.
pytest-timeout simply calls pytest.fail()
if you use the SIGALRM method, which you appear to be using. In turn that raises pytest.fail.Exception
.
Where are you planning to catch this though?
We're using pytest-timeout, thanks. The pytehon official documentation suggests using finalizers to learn the status of the test call. And this is what we're trying to do. We got this code:
We're using
asyncio-0.18.3, anyio-3.5.0, timeout-2.1.0, order-1.0.1
. In case of timeout we get traces like this:I skipped some internal logs, but tried to leave the most needed.
So is this a known problem? To me it looks like timeout happened in some test
test_availability_checker
, and then pytest tried to run setup and teardown of another testtest_role_password_reset
, right? Is this related to pytest-timeout at all?