Flaky `TestHandlerUpdateError` on macOS with race detector

[bigbes]

Summary

TestHandlerUpdateError (pool/pool_test.go:1561) intermittently fails on the testing_mac_os (1.24, macos-15) job in the Run race tests step.

Failure

Observed in run 25371363432, job 74395420704:

=== RUN   TestHandlerUpdateError
    pool_test.go:1590:
        Error Trace:    /Users/runner/work/go-tarantool/go-tarantool/tarantool/go-tarantool/pool/pool_test.go:1590
        Error:          Condition never satisfied
        Test:           TestHandlerUpdateError
--- FAIL: TestHandlerUpdateError (2.56s)
FAIL    github.com/tarantool/go-tarantool/v3/pool       24.184s

The failing assertion is the require.Eventuallyf at pool_test.go:1590 that waits for connPool.ConnectedNow(pool.ModeAny) to flip to false after switching the cluster to read-only.

Root cause

The Eventuallyf uses the package-shared timeout = defaultCountRetry * tick = 5 * 500ms = 2.5s (pool/pool_test.go:98-101). The test failed at 2.56s — i.e. it hit the deadline exactly, which means the pool's background reconnect/role-update cycle simply did not complete in time on macOS-15 + -race.

Commit a665a74 ("tests: fix flaky TestHandlerUpdateError timeout") replaced an earlier 100-iteration × 100µs busy-wait with Eventuallyf and the 2.5s shared timeout. That improved Linux runs, but 2.5s remains insufficient on macOS-15 under the race detector.

Related

• Closed predecessor for the older test name: TestConnectionHandlerUpdateError fails sometimes #560 (TestConnectionHandlerUpdateError).
• Most recent attempted fix: commit a665a74.

Suggested fix

Use a longer per-test timeout (e.g. 10s) for this Eventuallyf rather than the shared 2.5s constant. The poll interval is CheckTimeout = 100µs, so increasing the ceiling adds no cost on the happy path.