search

charmed-kubernetes / pytest-operator

Apache License 2.0
7 stars 13 forks source link

Asyncio_mode warnings fired by plugin.py #50

Open PietroPasotti opened 2 years ago

PietroPasotti commented 2 years ago

I get a bunch of these warnings when running the tests.

.tox/integration/lib/python3.8/site-packages/pytest_asyncio/plugin.py:191
  /home/pietro/canonical/charm-prometheus-node-exporter/.tox/integration/lib/python3.8/site-packages/pytest_asyncio/plugin.py:191: DeprecationWarning: The 'asyncio_mode' default value will change to 'strict' in future, please explicitly use 'asyncio_mode=strict' or 'asyncio_mode=auto' in pytest configuration file.
    config.issue_config_time_warning(LEGACY_MODE, stacklevel=2)

Maybe some develop branch is already preparing for these changes/upgrading a dependency version, but, to make sure...

ca-scribner commented 2 years ago

I don't think anyone is fixing this, but I believe it gets fixed by changing this line to @pytest_asyncio.fixture as discussed here. Otherwise, passing pytest the --asyncio-mode=auto command line arg will also sort this out.

ca-scribner commented 2 years ago

Actually sorry there's two warnings that pop up, and the fix I propose is more directly related to the other.

I don't think there's anything that can "fix" this deprecation warning at the pytest-operator level. I believe this must be addressed by the user calling pytest --asyncio-mode=auto or =strict. =strict might not work as expected though unless we also implement the @pytest_asyncio.fixture change mentioned above.

ca-scribner commented 2 years ago

FYI, for anyone coming to this after seeing an odd change in your code's behaviour, it might be because pytest-asyncio v0.19.0 changed the default valut of async-mode from auto to strict

ca-scribner commented 2 years ago

A link to a deeper dive after some more research

PietroPasotti commented 11 months ago

Experiencing some related issues right now. Apparently pytest-operator is getting stuck for hours https://github.com/canonical/traefik-k8s-operator/actions/runs/7083208411/job/19275228212?pr=279 waiting on something

jnsgruk commented 11 months ago

If you pin pytest-asyncio==0.21.1 it'll work again.

There was a change in pytest-asyncio 0.23.0 that deprecated something this repo uses: https://github.com/pytest-dev/pytest-asyncio/releases/tag/v0.23.0

In pytest-operator, we mess with the event loop here: https://github.com/charmed-kubernetes/pytest-operator/blob/ab50fc20320d3ea3d8a37495f92a004531a4023f/pytest_operator/plugin.py#L171-L176

PietroPasotti commented 11 months ago

If you pin pytest-asyncio==0.21.1 it'll work again.

There was a change in pytest-asyncio 0.23.0 that deprecated something this repo uses: https://github.com/pytest-dev/pytest-asyncio/releases/tag/v0.23.0

In pytest-operator, we mess with the event loop here:

https://github.com/charmed-kubernetes/pytest-operator/blob/ab50fc20320d3ea3d8a37495f92a004531a4023f/pytest_operator/plugin.py#L171-L176

yarp: #119

phvalguima commented 11 months ago

Hi team, @jnsgruk++ @PietroPasotti++ for the proposal.

One thing I noticed is that pytest-operator + v0.23.2 pytest-asyncio results in we calling Python's asyncio mechanism with a brand new event loop, with no tasks in it nor any ready tasks yet. In my opinion, that should return rightaway. However, Python's _run_once with a fresh new event loop results in epoll_wait being called with timeout=-1:

Specifying a timeout of -1 causes epoll_wait() to block indefinitely

That is why we were hanging forever.

I filed a bug with Python: https://github.com/python/cpython/issues/112741, explaining we are missing a condition to catch this corner case.