Repository navigation
Conversation
|
Sorry, but as explained in #30851 (comment), the diagnosis stated here is not correct. Therefore, any PR based on that is not a solution. As mentioned in that post, we do not yet know the root cause, and that means we don’t know the proper fix. |
|
@timhoffm we should take a look on azure ci tests by reruning them after opening the pr again |
|
No.
pandas-based tests do not have relevant setup costs. |
I does as you said by grouping method |
😆 That's the art. Analyse the available information, think hard, build a hypothesis, try to verify it, possibly iterate that multiple times until we are convinced we have understood it. |
|
@timhoffm so I should not do anything for now? |
|
You could do the above stuff if you feel your up to it. We don't have a recipe to tell you do x and y and then it's solved. This is how real problems work 😄. |
|
Thanks for guidance chief @timhoffm |
PR summary
This PR addresses the flaky timeouts observed in the Windows CI environment (and potentially others) where test_backends_interactive.py subprocesses would hang or time out.
Diagnosis
Detailed profiling and discussion (thanks @rcomer and @timhoffm) revealed a Resource Contention issue rather than a simple slow test:
The "Bully": lib/matplotlib/tests/test_axes.py contains pandas-based tests (specifically test_bar_pandas_indexed) that have a heavy setup cost (~2s on a fast local machine, likely 10s+ on CI).
The "Victim": lib/matplotlib/tests/test_backends_interactive.py launches fragile subprocesses that require timely I/O and CPU resources to initialize backends.
The Conflict: When pytest-xdist scheduled these two files on different workers simultaneously, the resource contention caused the subprocesses to starve and eventually time out.
The Fix
Instead of disabling parallelism globally or instrumenting the subprocesses (which is complex), this PR implements a Grouped Isolation Strategy:
Enabled loadgroup: Added --dist loadgroup to azure-pipelines.yml.
Shared Group Tag: Applied @pytest.mark.xdist_group("heavy_resource_group") to both:
lib/matplotlib/tests/test_axes.py
lib/matplotlib/tests/test_backends_interactive.py
Result: This forces both test modules to run sequentially on the same worker (e.g., both on gw0), ensuring they never execute in parallel. The rest of the test suite remains parallelized.
Verification
Verified locally with python -m pytest -n 2 --dist loadgroup .... Both the heavy pandas tests and the interactive backend tests were assigned to the same worker (gw0), confirming the serialization logic works.
@rcomer: Thanks for the --dist loadgroup pointer; it was the missing piece to enforce the markers.
@timhoffm: I opted for this isolation strategy first as it removes the root cause (contention). If flakes persist, I have a "Plan B" patch ready to add faulthandler instrumentation to the subprocesses to debug the specific hang points.
PR checklist
" is in the body of the PR description to link the related issue