Fix exceptions encountered during tests with python 3.11

[netomi]

There are various exceptions during test execution when run on python 3.11:

These seems to be related to this issue:

https://github.com/python/cpython/issues/109538

This PR adds the workaround as described in the ticket.

[netomi]

hmm, this fixes the other error it seems but creates a new error with dynamodb that I did not see locally, need to investigate.

[JWCook]

Thanks for looking into this. Since this is new behavior as of 3.11.5, another option would be to update the github action to use 3.11.4, and hope this will be fixed in a future patch release.

[netomi]

that would be an option. Something that bothers me is the test execution in general. I see from the execution on GitHub, that 2 processes are spawned:

gw0 I / gw1 I
gw0 [507] / gw1 [507]

that seems to come from

  XDIST_ARGS: '--numprocesses=auto --dist=loadfile'

The tests succeed in general. However, if I run the same command on my local machine some of the tests fail, e.g. when run with --numprocesses=2 to simulate the GitHub action environment. The tests only succeed locally when run in a single process.

tn@proteus:~/workspace/netomi/aiohttp-client-cache$ poetry run pytest -rs --numprocesses=2 test/integration
=============================================================================================== test session starts ===============================================================================================
platform linux -- Python 3.10.12, pytest-7.4.3, pluggy-1.2.0
rootdir: /home/tn/workspace/netomi/aiohttp-client-cache
plugins: xdist-2.5.0, clarity-1.0.1, cov-2.12.1, asyncio-0.14.0, aiohttp-0.3.0, forked-1.6.0
gw0 [513] / gw1 [513]
.....F.......................................FF....................F.........................F.........FFFFFFF.FF......FFFFFFFFFFFFFF.FFF.................................................................. [ 39%]
......................................................................................................................F.................................................................................... [ 79%]
...F.........................................................................F.....................F.....F.                                                                                                 [100%]
==================================================================================================== FAILURES =====================================================================================================

Its most likely because the tests are run in parallel but access the same test-resources and thus the assumptions being made in the test are not valid anymore. However, I dont understand why it succeeds on GitHub?

[JWCook]

What errors are you seeing locally?

The --dist=loadfile option parallelizes the tests by test module, so the integration tests won't be running more than one test at a time for a given backend. The only issues I've seen in the past when using xdist is when parallelizing by test function (default/--dist=load).

[netomi]

oh that is the trick I was missing, ty.

[JWCook]

The main difference between local and CI environments is the resources available. GitHub Actions runners only have 2 cores, so at most only 2 tests will run at a time, while your local machine is probably able to run 8+ at a time. So if there's a race condition, it's less likely to show up in GitHub Actions. It's possible that this event_loop fixture isn't thread- or multiprocess-safe.

[netomi]

ok pinned the 3.11 for now, test execution looks very clean now.