[RonnyPfannschmidt]

Written by Claude Opus 5.5 via Claude Code for the pytest maintainers; I prompted it, it did the work, I read it.

Closes #9236.

#9236 is not a garbage-collected handler, and #11123 did not fix it. It is a pluggy bug that pluggy 1.6.0 fixed (pytest-dev/pluggy#546), and it is still reachable because pytest allows pluggy>=1.5.

Mechanism

• pluggy < 1.6 re-raises out of the teardown loop in _multicall when an old-style hookwrapper raises in its own teardown. Every remaining teardown is skipped.
• The logging plugin's pytest_runtest_call wrapper is one of them. It stays suspended inside _runtest_for, still holding its entered catching_logs contexts, kept alive by a cycle through the exception traceback.
• When gc finalises it, catching_logs.__exit__ removes caplog_handler from the root logger. There is one handler per plugin, so that is the same object the next test's caplog just attached, and that test records nothing.

The reproducer from the issue still fails on current main with pluggy 1.5.0 and passes with 1.6.0. Bisecting pluggy points to pytest-dev/pluggy#546.

Change

• pluggy>=1.6,<2 in pyproject.toml and uv.lock. pluggy 1.6 needs Python >= 3.9, so there is no conflict with our >= 3.10.
• A regression test in testing/logging/test_fixture.py. It fails on pluggy 1.5.0 and passes on 1.6.0. It runs in a subprocess because in-process the HookRecorder keeps the failing call's CallInfo, whose traceback keeps the suspended wrapper alive, so the bug never shows.