test setup: unit suite cannot run under xdist — execnet cannot serialize MagicMock (silently drops ~2800 tests)

[KonstantinMirin]

Testing setup only — no production code changes.

Problem

tests/unit/ cannot run under pytest-xdist. tox.ini:65 therefore pins it serial by
default (-n {env:UNIT_XDIST_N:0}), and unit is the largest suite in the repo (6031
items), so this is the single biggest serial block in a full run.

Setting UNIT_XDIST_N=16 produces:

16 workers [6031 items]
INTERNALERROR> execnet.gateway_base.DumpError: can't serialize <class 'unittest.mock.MagicMock'>
INTERNALERROR> AssertionError: ('tests/unit/test_tenant_name_sync.py::test_context_processor_handles_missing_tenant', <WorkerController gw13>)
unit: exit 3 (112.65 seconds)

test_context_processor_handles_missing_tenant produces a failure payload containing a
MagicMock. execnet (xdist's wire protocol) cannot pickle it, the worker raises an
internal error, and that kills the whole session.

Why this is worse than a plain failure

The run reports 6031 items collected, 3183 reported — roughly 2,800 unit tests
silently never reported — while the JSON summary reads passed: 3152, failed: 0.
A green-looking report over a third of a missing suite. Only the tox exit code (3) and
the collected-vs-reported delta reveal it.

What's needed

• Make the test's failure payload serializable (don't let a MagicMock reach the
  assertion/repr that crosses the worker boundary).
• Sweep tests/unit/ for the same shape — anything that can put a mock into a failure
  repr is a latent instance of this.
• Then flip the UNIT_XDIST_N default off serial and confirm collected == reported.

Acceptance

• UNIT_XDIST_N=16 (and auto) completes with no INTERNALERROR.
• Collected count equals reported count in unit.json.
• Suite result is identical serial vs parallel.

Notes

Self-contained and independent of #2007/#2008/#2009/#2010 — this one can land on
its own and immediately parallelizes the largest suite.

[KonstantinMirin]

Additional diagnosis — the crash is test-ordering dependent, not a fixed property of the test.

Local repro attempt, full unit+harness set at the same worker count, but with -p no:randomly:

DATABASE_URL= uv run pytest tests/unit/ tests/harness/ -n 16 -q --tb=line -p no:randomly
===== 1 failed, 5993 passed, 11 skipped, 26 xfailed, 99 warnings in 46.31s =====

No INTERNALERROR, no DumpError, collected == reported. The single failure was an unrelated known one.

tox.ini's unit env does not pass -p no:randomly (the integration env does), so unit runs under pytest-randomly. Combined with xdist's default --dist load, the ordering that makes test_context_processor_handles_missing_tenant fail — and thus emit a failure repr carrying a MagicMock that execnet cannot pickle — only occurs on some seeds.

Implications for whoever picks this up:

• Reproducing needs the failing seed, not just -n 16. Capture -p randomly seed from the failing run and pin it with -p randomly --randomly-seed=<N>.
• There are likely two defects: (a) the test is order-dependent (shares Flask app / patched global state), and (b) a failure repr containing a MagicMock is unserializable, which turns any such failure into a session-killing INTERNALERROR rather than one reported failure. (b) is the more dangerous one — it would mask any order-dependent failure the same way.
• Also worth deciding whether unit should adopt -p no:randomly like integration, or keep randomization and fix the order dependence.

Unit stays serial (UNIT_XDIST_N=0) meanwhile, per owner decision — so this is not currently blocking measurement.