Skip to content

PATTERN Cited by 1 source

Deterministic test for timing bug

Deterministic test for timing bug is a testing pattern where the environmental condition that triggers a race condition is simulated with a controlled mock, making the non-deterministic bug reproducible on every test run.

The Problem

Timing-sensitive bugs typically cannot be reproduced reliably with standard test infrastructure: - They depend on specific load, concurrency, or I/O pacing. - Adding instrumentation changes timing (Heisenbug effect). - Local environments differ from production in scheduling and buffer sizes.

The Pattern

Instead of attempting to reproduce the real-world timing window, simulate the exact I/O condition that triggers the race:

  1. Identify the precise state that causes failure (e.g., "socket buffer full after first chunk").
  2. Build a mock/wrapper that deterministically creates that state.
  3. Write a test that asserts correct behavior under that simulated condition.

Cloudflare's Implementation

To test the hyper race condition, Cloudflare built a custom TCP stream wrapper that: - Accepted 8 KB on the first write call. - Returned Poll::Pending on every subsequent write (simulating a permanently full socket buffer).

The test sent a 500 KB response through this constrained mock and verified that hyper did not call shutdown while 492 KB remained buffered. Without the fix, it did; with the fix, it waited (Source: sources/2026-06-22-cloudflare-how-we-found-a-bug-in-the-hyper-http-library).

When to Use

  • Race conditions that depend on I/O timing or buffer fullness.
  • Bugs that only manifest under production concurrency.
  • Upstream contributions where a reproducible test is required for acceptance.

Seen In

Last updated · 559 distilled / 1,651 read