Asyncio_mode warnings fired by plugin.py

[PietroPasotti]

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]

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]

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]

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]

A link to a deeper dive after some more research

[PietroPasotti]

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]

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:

pytest-operator/pytest_operator/plugin.py

Lines 171 to 176 in ab50fc2

	@pytest.fixture(scope="module")
	def event_loop():
	"""Create an instance of the default event loop for each test module."""
	loop = asyncio.get_event_loop_policy().new_event_loop()
	yield loop
	loop.close()

[PietroPasotti]

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:

pytest-operator/pytest_operator/plugin.py

Lines 171 to 176 in ab50fc2

	@pytest.fixture(scope="module")
	def event_loop():
	"""Create an instance of the default event loop for each test module."""
	loop = asyncio.get_event_loop_policy().new_event_loop()
	yield loop
	loop.close()

yarp: #119

[phvalguima]

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: python/cpython#112741, explaining we are missing a condition to catch this corner case.