TestAdaptiveImmediatePromote_Epoll fails when one /ping run takes over 2 ms, which -race plus coverage on a hosted runner can cause

[FumingPower3925]

Summary

TestAdaptiveImmediatePromote_Epoll (async_promote_integration_linux_test.go:73) fails on a timing it does not control.

• The test asserts that the fast route /ping is never promoted. It sends /ping in a readiness loop and then once more.
• A route is promoted after a single inline run longer than adaptiveBlockingThreshold (2 ms) (handler.go:186).
• Under -race plus -covermode=atomic on a 4-vCPU GitHub runner, one /ping run can take longer than 2 ms. The route is then promoted, and the test fails with /ping (fast) must not be promoted.

Observed

• Where: the Coverage workflow (test-coverage.yml, root package, -race -covermode=atomic) on PR test(websocket): the backpressure oracles wait on progress and read while they wait, judge every give-up with both ends' timeline, and fail a connection the engine stops reading (celeris#633, celeris#623, celeris#611, celeris#607 class) #749, job 108686788724, run 36343065211 attempt 1.
• PR test(websocket): the backpressure oracles wait on progress and read while they wait, judge every give-up with both ends' timeline, and fail a connection the engine stops reading (celeris#633, celeris#623, celeris#611, celeris#607 class) #749 does not touch the root package. It changes only middleware/websocket test files.
• The re-run passed: same run, attempt 2 (the failed job re-run once).
• The test itself took 0.01 s, so this is a single slow run, not a hang.

--- FAIL: TestAdaptiveImmediatePromote_Epoll (0.01s)
    async_promote_integration_linux_test.go:73: /ping (fast) must not be promoted

Why it is the test

The test's own premise is that one run over 2 ms promotes a route. It then requires a real handler to stay under 2 ms on every run, on a shared runner, under the race detector and coverage instrumentation.

The coverage job is informational, so this does not block merges. It will still read as a red Coverage check on unrelated pull requests.

Direction

The assertion has to hold whatever the runner's scheduling. Two options:

• Make the fast route's runs provably fast in what the router measures, for example by stubbing the clock the promotion decision reads, as the adaptive dispatch never re-times a settled route: a store-backed handler that turns slow runs inline on the engine worker forever (#493 item 4, measured) #592 rigs do.
• Or assert on the route's recorded run durations: /ping must not be promoted unless one of its runs was actually measured over the threshold.

The #622 lesson applies: an absolute latency bar on a hosted runner measures the runner.

[FumingPower3925]

Seen again on main fe9264f (#808's merge), push Coverage run 36572760158, attempt 1: async_promote_integration_linux_test.go:73: /ping (fast) must not be promoted, root package 196.8 s under -race + coverage. The failed job was rerun once.