Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.76%. Comparing base (4bae30a) to head (98c3785).

@@           Coverage Diff           @@
##           master    #1711   +/-   ##
=======================================
  Coverage   99.76%   99.76%           
=======================================
  Files          33       33           
  Lines        3426     3427    +1     
  Branches      471      471           
=======================================
+ Hits         3418     3419    +1     
  Misses          5        5           
  Partials        3        3           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Merging this PR will not alter performance

✅ 6 untouched benchmarks

_{Comparing bluetoothbot:koan/speed-up-register-random-wait (98c3785) with master (4bae30a)}

all the windows TC tests fail with this pr

    zeroconf:outgoing.py:471 now offsets = questions=1, answers=302, authorities=0, additionals=0
================================== FAILURES ===================================
__________________ test_tc_bit_defers_last_response_missing ___________________

    @patch.object(_listener, "_TC_DELAY_RANDOM_INTERVAL", (10, 20))
    def test_tc_bit_defers_last_response_missing():
        zc = Zeroconf(interfaces=["127.0.0.1"])
        _wait_for_start(zc)
        type_ = "_knowndefer._tcp.local."
        name = "knownname"
        name2 = "knownname2"
        name3 = "knownname3"
    
        registration_name = f"{name}.{type_}"
        registration2_name = f"{name2}.{type_}"
        registration3_name = f"{name3}.{type_}"
    
        desc = {"path": "/~paulsm/"}
        server_name = "ash-2.local."
        server_name2 = "ash-3.local."
        server_name3 = "ash-4.local."
    
        info = r.ServiceInfo(
            type_,
            registration_name,
            80,
            0,
            0,
            desc,
            server_name,
            addresses=[socket.inet_aton("10.0.1.2")],
        )
        info2 = r.ServiceInfo(
            type_,
            registration2_name,
            80,
            0,
            0,
            desc,
            server_name2,
            addresses=[socket.inet_aton("10.0.1.2")],
        )
        info3 = r.ServiceInfo(
            type_,
            registration3_name,
            80,
            0,
            0,
            desc,
            server_name3,
            addresses=[socket.inet_aton("10.0.1.2")],
        )
        zc.registry.async_add(info)
        zc.registry.async_add(info2)
        zc.registry.async_add(info3)
    
        protocol = zc.engine.protocols[0]
        now = r.current_time_millis()
        _clear_cache(zc)
        source_ip = "203.0.113.12"
    
        generated = r.DNSOutgoing(const._FLAGS_QR_QUERY)
        question = r.DNSQuestion(type_, const._TYPE_PTR, const._CLASS_IN)
        generated.add_question(question)
        for _ in range(300):
            # Add so many answers we end up with another packet
            generated.add_answer_at_time(info.dns_pointer(), now)
        generated.add_answer_at_time(info2.dns_pointer(), now)
        generated.add_answer_at_time(info3.dns_pointer(), now)
        packets = generated.packets()
        assert len(packets) == 4
        expected_deferred = []
    
        next_packet = r.DNSIncoming(packets.pop(0))
        expected_deferred.append(next_packet)
        threadsafe_query(zc, protocol, next_packet, source_ip, const._MDNS_PORT, Mock(), ())
        assert protocol._deferred[source_ip] == expected_deferred
        timer1 = protocol._timers[source_ip]
    
        next_packet = r.DNSIncoming(packets.pop(0))
        expected_deferred.append(next_packet)
        threadsafe_query(zc, protocol, next_packet, source_ip, const._MDNS_PORT, Mock(), ())
>       assert protocol._deferred[source_ip] == expected_deferred
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
E       KeyError: '203.0.113.12'

try harder

@bluetoothbot rr

PR Review — test: shave register/shutdown/TC waits on loopback

Mechanics are clean and the speedups are real: extracting _REGISTER_RANDOM_INTERVAL to a module constant keeps production behavior identical while letting quick_timing patch it on loopback, and the test_integration got_query.wait() synchronization correctly closes the race the faster register introduced. The blocking issue is what @bdraco already flagged: test_tc_bit_defers_last_response_missing is failing on the Windows CI matrix because the new _TC_DELAY_RANDOM_INTERVAL patch to (10, 20)ms is below Windows' default ~15.6ms timer tick. That patch isn't visible in the truncated diff but it's the load-bearing change for that test. Once that interval is widened enough to clear Windows clock granularity (see reply), this is mergeable. Secondary nit: the 0.1s _TASK_AWAIT_TIMEOUT reduction is aggressive — worth widening for safety on slow CI entries.

🟢 Suggestions

@patch.object(aioutils, "_TASK_AWAIT_TIMEOUT", 0.1)
def test_shutdown_loop() -> None:
    ...
        asyncio.run_coroutine_threadsafe(_still_running(), loop).result(0.1)

Checklist

• Production behavior preserved (constant default matches old inline literal)
• Test races eliminated by explicit synchronization
• Platform portability of new timing constants — existing comment from @bdraco — Windows TC test failure
• Sufficient timeout headroom for slow CI / PyPy / free-threaded matrix — suggestion ＃1
• Free-threaded (3.14t) safety — no new module-level mutable state
• RFC citations preserved on timing comments
• No Co-Authored-By trailer in commits
• Conventional Commits PR title with lowercase subject

Summary

Mechanics are clean and the speedups are real: extracting _REGISTER_RANDOM_INTERVAL to a module constant keeps production behavior identical while letting quick_timing patch it on loopback, and the test_integration got_query.wait() synchronization correctly closes the race the faster register introduced. The blocking issue is what @bdraco already flagged: test_tc_bit_defers_last_response_missing is failing on the Windows CI matrix because the new _TC_DELAY_RANDOM_INTERVAL patch to (10, 20)ms is below Windows' default ~15.6ms timer tick. That patch isn't visible in the truncated diff but it's the load-bearing change for that test. Once that interval is widened enough to clear Windows clock granularity (see reply), this is mergeable. Secondary nit: the 0.1s _TASK_AWAIT_TIMEOUT reduction is aggressive — worth widening for safety on slow CI entries.

Automated review by Kōana22d068
6b84b72
98c3785

@bdraco: all the windows TC tests fail with this pr

The Windows failure is almost certainly the combination of two compounding factors in test_tc_bit_defers_last_response_missing:

1. _TC_DELAY_RANDOM_INTERVAL=(10, 20) is below the Windows scheduler tick (~15.6ms). The asyncio call_later driving the TC defer timer floors at the next tick, so the effective fire time is 15-30ms+ rather than the 10-20ms the patch suggests.

2. The cleanup poll budget was halved — range(8) × sleep(0.1) = 800ms became range(20) × sleep(0.02) = 400ms. Under Windows' coarser time.sleep granularity the wall clock is closer to 620ms, but the asyncio side is racing the same tick and can easily overshoot.

Two options to fix:

• Keep the 800ms cleanup budget (range(40) × sleep(0.02) if you want the finer-grained early exit), or
• Widen the patched random interval to something like (20, 50) or (30, 60) ms — still a 10x speedup over the production (400, 500) ms, but well clear of the Windows tick floor so the timing is deterministic across the CI matrix.

I'd lean toward the second — it preserves the speedup intent of the PR without making the cleanup poll do double duty as a slack budget for scheduler jitter.

Rebase with requested adjustments

Branch koan/speed-up-register-random-wait was rebased onto master and review feedback was applied.

Changes applied

• CI fix: Applied pre-push CI fix
• CI fix: Pre-push CI fix applied

Stats

5 files changed, 23 insertions(+), 9 deletions(-)

CI status

CI will be checked asynchronously.

Automated by Kōan

@bluetoothbot rr

@bdraco: all the windows TC tests fail with this pr

The root cause is almost certainly Windows' default timer resolution. CPython's asyncio on Windows uses the system clock tick, which defaults to ~15.6ms (64Hz) unless something has called timeBeginPeriod(1). Patching _TC_DELAY_RANDOM_INTERVAL to (10, 20)ms means the lower bound (10ms) is below a single tick — the wait either returns immediately on the current tick boundary or has to wait a full ~15.6ms regardless, so the deferred response timing the test polls for becomes non-deterministic across the (10, 20)ms band.

Two viable fixes:

1. Widen the patch to something safely above one Windows tick, e.g. (50, 100) or (100, 200). Still a meaningful shave vs. the production (400, 500)ms — the test would land around 0.4-0.5s instead of 0.32s, still well below the 0.79s baseline.

2. Skip the patch on Windows via @pytest.mark.skipif(sys.platform == 'win32', ...) on just the patched variant, or branch the interval: (50, 100) if sys.platform == 'win32' else (10, 20).

Option 1 is the cleaner call — it keeps the test exercising the same code path on all platforms, just with a wider RFC 6762 §7.2 defer window that all OS timer resolutions can resolve. The poll loop's cleanup window would need to widen correspondingly to stay above the upper bound.

The diff snippet you pasted shows the patch is applied at function level — that's the right scope, just needs a Windows-safe value.

@bluetoothbot rr

Superseded — most of this PR's content (extracting _REGISTER_RANDOM_INTERVAL, patching it in quick_timing, the test_shutdown_loop cleanup) was landed in #1760 under the constant name _PROBE_RANDOM_DELAY_INTERVAL. Branch had diverged too far for a clean rebase. The one remaining novel bit — the got_query.wait() synchronisation in test_integration (needed now that register can finish before the browser's first query fires) — is being reopened as a fresh PR.

Replacement opened: #1771 (test sync fragment only — everything else this PR proposed was already landed in #1760).