A staff diag endpoint returns 409 wrong_worker when a ?pid= query param doesn't match os.getpid(). The test probed it with ?pid=1, on the assumption pid 1 is never the test process.
Under CI that held (pytest-xdist workers are forked children, never pid 1). Run the same file the plain way inside the container -- docker compose run --rm tests python -m pytest path/to/test_x.py -- and python IS pid 1, so the endpoint saw its own pid, skipped the 409, and actually forked a real heap dump. The test failed locally for a reason unrelated to the CI failure being debugged, which cost a debugging cycle.
Fix: derive a pid that is wrong by construction rather than by assumption -- os.getpid() + 1. The endpoint only compares for inequality, so the pid need not exist.
General rule: any test constant justified by "this can never be us" (pid 1, port 1, uid 0, hostname localhost) needs re-checking under containers and under PID-1 init behavior. Derive from the runtime value instead.
Second, related lesson from the same failure: a test that fork-dumps the test process's own heap has a runtime that scales with the accumulated heap of its xdist worker (~900MB RSS by the end of a shard) multiplied by CPU contention from siblings. It went 59s -> 118s -> past a 120s poll deadline over two days of unrelated commits. Raising the deadline only buys time; route the test to a lower-parallelism CI job (marker-based shard) and size the deadline for growth.