Well it passes here 🎉 Comparing with latest main (that failed), the same number of tests were run, and the test time was about a minute slower here, which all checks out.

Trying to power-cycle, but apparently azure pipeline results are cached and not rerun 😞.

Ok second try (only reworded commit message to let azure believe this is new). Let's see if we can get this passing multiple times.

Second run also successful.

Yet another rewording. Three's the charm.

4 errors (two look like timeouts, one looks like a failure to read back a png and the last is some random test later when the warning about unclosed files got raised during GC and pytest failed the test it was in).

One of the failing tests was not marked with the xdist_group. -> fix and retry.

First test run after fix successful. Force-push to re-run a second time.

The annulus test that is failing is a bit pathological and there are two tests that share the same baseline image, I'm going to push a commit merging them.

There is a lock for re-used filenames, but it is only used if you re-use a filename in thesame test, so it is best to merge these, even if it would just be two figures in one test (which I don't think you did anyway.)

It is a bit aggressive to backport this PR, if anyone has the slightest concern lets not.

If we are correct that the problem is trying to launch simultaneous subprocesses from the pytest-xdist workers, do we have any theory as towhy this is a problem? This seems like something that should be safe.

My best guess (I did look at the source ofsubprocess.py to try and verify this guess and was clear to me that would take more time than I can spend right now) is that the way xdist creates the additional workers the filehandles that are generated for the pipes are shared and hence we get the cross talk between the workers.

I'm also not clear on the mechanics in the background, but the issues liked in#29797 (comment) indicate that there can be interplay between the subprocesses and timeout handling, and that could be specific to windows.

It's a bit weird that it only(?) happens for Python 3.10/3.11. I'm inclined to limit the the--distgroup parameter to only 3.11. First because we then still test a with unsynced subprocesses and if 3.12/3.13 exhibit the error we are more sure it's a discriminating factor. Second, if it does not happen in 3.12/3.13 anymore, we can phase the usage of distgroups out when dropping 3.11, and remove unnecessary overhead.

The recent change showed the timeout again. Can somebody with more pipeline configuration skills please verify whether my attempt to apply--dist=loadgroup only to the py3.11 pipeline is valid?

I'm not sure thatPYTHON_VERSION is actually set anywhere; it appears to be a leftover from when we didPre-release testing. Ithink you need to use$(python.version) to fetch the runtime variable defined by the matrix.

I still have an echo statement in azure-pipelines.yml to veryify the code works as intended. It does. I'm letting the CI complete to get another data point on "this does not time out". When that's complete, I'll remove the echo.

Everything seems to work. Echo removed.

Got a timeout, and found out there were more tests using subprocesses, which weren't yet in the xdist_group. Added them.

Let's put this on hold in favor of#29992.

Superseeded by#29992.