Skip to content

CI: [diagnostic, do not merge] Test pytest with third-party plugins disabled - #712

Closed
echoix wants to merge 1 commit into
mainfrom
ci-diag-disable-plugins-latest
Closed

echoix wants to merge 1 commit into
mainfrom
ci-diag-disable-plugins-latest

Conversation

@echoix

@echoix echoix commented Sep 26, 2026

Copy link
Copy Markdown
Owner

Purpose

Tenth diagnostic. pytest auto-loads every installed plugin's
entry_points at startup regardless of which command-line flags are
used -- meaning pytest-xdist, pytest-randomly, and pytest-timeout
(and execnet, pytest-xdist's own transport dependency) all get
imported and register hooks even in a plain, single-process, no-"-n"
pytest run that never actually spawns workers, randomizes order, or
sets a timeout.

Ruled out so far in this investigation: xdist itself
(ci-diag/no-xdist-single-process), the pytest.exe launcher stub
(ci-diag/python-m-pytest-vs-exe), pytest-timeout's watchdog thread
(checked directly in its source -- it does not start until after
collection succeeds), fd-level output capturing
(ci-diag/no-capture-test), environment changes from the pip install
step (ci-diag/standalone-import-after-pip), and GRASS's own source
code (the crash reproduces identically whether tested against the
stale diagnostic base this investigation started with, or the actual
current main tip -- see ci-diag/confirm-on-latest-main). Every native
dependency (GDAL, curl, OpenSSL, libjpeg-turbo, expat, PROJ,
msvcrt2019, the MSVC mutex-hack state) has also been confirmed clean
or unchanged via direct binary diffing.

What this PR does

Disables every third-party pytest plugin explicitly
(`-p no:xdist -p no:randomly -p no:timeout -p no:cacheprovider`), to
see whether bare, plugin-free pytest core collection alone still
crashes with `Windows fatal exception: code 0xc0000139`, or whether
one of these auto-loaded plugins (most likely execnet, pulled in by
pytest-xdist) is actually responsible.

This PR is for CI investigation only and is not meant to be merged.

🤖 Generated with Claude Code

pytest auto-loads every installed plugin's entry_points at startup
regardless of which command-line flags are used, meaning
pytest-xdist, pytest-randomly, and pytest-timeout (and execnet,
pytest-xdist's own transport dependency) all get imported and
register their hooks even in a plain, single-process, no-"-n" pytest
run that never actually uses xdist workers, randomization, or a
timeout.

Every other angle has been ruled out in this investigation: xdist
itself, the pytest.exe launcher stub vs python -m pytest,
pytest-timeout's watchdog thread (checked directly in its source: it
does not start until after collection succeeds), fd-level output
capturing (--capture=no), environment changes from the pip install
step (a plain python import still succeeds afterwards), and GRASS's
own source code (the crash reproduces identically on both the stale
diagnostic base and the current main tip).

This disables every third-party plugin explicitly via -p no:X, to see
whether bare, plugin-free pytest core collection alone still crashes,
or whether one of these auto-loaded plugins is actually responsible.

Temporary, for CI investigation only.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant