Close the guard's blind spot: named short timeouts

A fifth flake landed on CI while the first guard was in review —
GossipSyncBoardTests timing out at 1.03s — and the guard did not catch it,
because the deadline was `TestConstants.shortTimeout` rather than a
literal. A literals-only scan cannot see a short value behind a symbol,
which is the more common way it is written: 81 wait sites used
shortTimeout (1s) or defaultTimeout (5s), every one of them below the
floor.

Rather than guess which of those were safe to raise, all 81 were converted
and the suite timed. Runtime went 15s -> 72s, which located the genuine
negative waits precisely: ten tests that assert something does *not*
happen and therefore always run their deadline out. Measurement instead of
a heuristic, since a mis-guess in either direction is invisible — too
short reintroduces the flake, too long silently costs a minute a run.

Those 28 sites now use `TestConstants.negativeWaitWindow`, a named
constant whose doc explains the inverted reasoning: for a negative wait,
starvation can only make the assertion *more* likely to hold, so short is
correct, and the name states the polarity instead of leaving a bare
literal that reads like the mistake. Suite is back to 15.3s.

The guard now also rejects `timeout: TestConstants.shortTimeout` and
`defaultTimeout`, while accepting `negativeWaitWindow` by name.

Re-verified with a canary carrying every banned shape — literal default,
both named constants, and an elapsed-time upper bound. All four were
flagged with file and line; the suite went green again on removal.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
jack
2026-07-26 23:16:28 +01:00
co-authored by Claude Opus 5
parent ac13a0c22f
commit 2d58bbcfaf
11 changed files with 111 additions and 82 deletions
@@ -44,6 +44,21 @@ struct TestConstants {
/// latency assumption in disguise.
static let minimumSettleTimeout: TimeInterval = 10.0
/// For waits whose **expected outcome is `false`** "prove this does not
/// happen".
///
/// The floor above is wrong for these, and inverted: a negative wait always
/// runs its deadline out, so `settleTimeout` would spend 30 s per case
/// proving nothing extra. Starvation cannot cause a false failure here
/// either a starved runner only makes the thing *less* likely to happen,
/// so the assertion still holds. Short is correct, and naming it says the
/// polarity out loud instead of leaving a bare literal that reads like the
/// mistake this file exists to prevent.
///
/// `TestTimingHygieneTests` accepts this by name. Using it for a wait you
/// expect to succeed reintroduces exactly the flake class it sits next to.
static let negativeWaitWindow: TimeInterval = 1.0
static let testNickname1 = "Alice"
static let testNickname2 = "Bob"