pytest-dev
gateway: Test concurrent rinfo for main_thread_only
Add test coverage for a bug triggered by pytest-cov when it tried to call _rinfo after the gateway was already busy with a remote_exec call:
https://github.com/pytest-dev/pytest-xdist/issues/1071
Looks like something that would benefit from having an intentional test? And maybe some smoke tests with pytest-cov and pytest-xdist in the same env?
@bluetech @RonnyPfannschmidt @nicoddemus I can't request reviews in this repo so tagging you instead.
This PR looks ready to be checked/merged.
@zmedico Thanks for following up!
It seems to me better to merge https://github.com/pytest-dev/pytest-xdist/pull/1072 and not this. It seems intentional that execnet doesn't request rinfo always, allowing the user to choose whether to grab the info from the remote. But this change will "force" it.
The issue seems to me to be specific to xdist and pytest plugin architecture, where xdist can't control what another plugin does, otherwise it would simply avoid the issue.
WDYT?
@zmedico Thanks for following up!
It seems to me better to merge pytest-dev/pytest-xdist#1072 and not this. It seems intentional that execnet doesn't request rinfo always, allowing the user to choose whether to grab the info from the remote. But this change will "force" it.
The issue seems to me to be specific to xdist and pytest plugin architecture, where xdist can't control what another plugin does, otherwise it would simply avoid the issue.
WDYT?
Yes, I agree that is nicer to allow a choice here. I suppose pytest-cov is not in a position to cache the rinfo, so it makes sense for pytest-xdist to handle it for backward compatibility.
I've adjusted this PR to just add test_concurrent_rinfo, and perform the rinfo caching for main_thread_only right inside the test,
Noted the change here: https://github.com/pytest-dev/pytest-xdist/issues/1071#issuecomment-2081126133
@zmedico I admit I'm a bit confused what the test is testing. What is the failure it is testing against?