test: widen LOOPBACK_FIND_TIMEOUT under PyPy

bdraco · bdraco · commit 4cd4c586b9c0 · 2026-05-19T16:32:23.000-05:00
The 75ms loopback budget for ZeroconfServiceTypes.find() races PyPy's
JIT warmup the first time the path runs early in the suite. Two
back-to-back runs on master flaked at the same 21% point: one on
test_integration_with_listener and one on
test_integration_with_listener_v6_records. Bump the timeout to 300ms on
PyPy only; CPython keeps the existing 75ms budget.
diff --git a/tests/__init__.py b/tests/__init__.py
@@ -23,6 +23,7 @@
 from __future__ import annotations
 
 import asyncio
+import platform
 import socket
 import time
 from functools import cache
@@ -35,6 +36,8 @@
 
 _MONOTONIC_RESOLUTION = time.get_clock_info("monotonic").resolution
 
+_IS_PYPY = platform.python_implementation() == "PyPy"
+
 # get_service_info / async_request timeout for tests using the
 # `quick_request_timing` fixture. The fixture cuts the initial-query
 # delay to ~15ms (10ms _LISTENER_TIME + 1-5ms jitter), so 50ms is
@@ -49,7 +52,9 @@
 # the `quick_timing` fixture, which shrinks the browser's first-query
 # delay from RFC 6762 §5.2's 20-120ms window to 1-5ms; with that shave
 # the registrar's response lands inside ~10ms and 75ms is ~7x headroom.
-LOOPBACK_FIND_TIMEOUT = 0.075
+# PyPy's JIT is still warming up the first time this path runs early in
+# the suite, so the round trip is too slow for 75ms; give it more room.
+LOOPBACK_FIND_TIMEOUT = 0.3 if _IS_PYPY else 0.075
 
 # IPv6-only `find()` on Linux GitHub runners can hit `[Errno 101] Network
 # is unreachable` on the `::1` socket and falls back to the `fe80::` link-
