Raising four deadlines fixed the four tests that happened to fire. The
class was still there: fourteen separate waitUntil helpers, most defaulting
to 1.0s, plus wait call sites with literal budgets. The fifth instance
would have landed the same way, on someone else's unrelated PR.
The rule, now written down in TestConstants.settleTimeout: **a wait
deadline is not a latency budget.** It exists so a genuine hang eventually
fails the suite, so size it for the worst-case scheduler, never for how
long the operation should take. Waits return as soon as their condition
holds, so a generous deadline is free in the passing case and only extends
genuine failures.
- Every wait helper now defaults to TestConstants.settleTimeout (30s), and
the literal wait call sites below the floor were converted too — sixteen
sites across ten files.
- TestTimingHygieneTests enforces it by scanning the test sources: wait
defaults and wait call sites must be at least minimumSettleTimeout, and
no test may assert an upper bound on elapsed wall-clock time (the
assertion that started this, which cannot separate correct behaviour from
a slow machine).
- Both rules waive per line with "test-timing-ok: <reason>", accepted on
the line or in the comment block above it so the reason has room to be a
sentence. One legitimate use so far: a NEGATIVE wait in NoiseCoverageTests
asserting a promotion has *not* completed within 50ms, where a long
deadline would only make the suite slow while still passing.
Injected production timeouts are deliberately not matched — the Noise
handshake timeouts are the behaviour under test, and short values are
correct there.
Verified the guard actually fails: a canary file with both banned shapes
was flagged with file and line, and the suite went green again once it was
removed. Full suite passes with all 18 cores saturated.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Both surfaced on the CI runs for this PR and #1487, both in tests neither
PR touches, both the same shape as the two already fixed here: a deadline
sized for the work rather than for a runner executing many suites at once.
VoiceNotePlaybackControllerTests waited 5s for a @MainActor Task that
playback schedules for the session acquire and its failure path. When that
Task is not scheduled in time the helper reports *two* failures — the wait,
and the `!isPlaying` the un-run failure path has not reset yet — which
reads like a playback bug rather than a starved scheduler. That is exactly
what CI showed.
GeoRelayDirectoryTests waited 10s for work the directory runs in
Task.detached(priority: .utility); utility priority competes with every
other suite. The retry-scheduling case timed out at exactly 10.06s with the
retry never scheduled, reading like a missing retry rather than a starved
background task.
Raised to 30s each with the reasoning recorded at the helper. Both helpers
return as soon as their condition holds, so nothing slows down when tests
pass — only the genuine-failure case takes longer to report.
Verified 3x with all cores saturated: both suites clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Centralize PTT and voice audio-session ownership, harden courier/bridge/outbox delivery and recovery, correct location and delivery-state races, add privacy/release metadata, and ship reproducible universal Arti slices with Release CI coverage.
Validated by the full iOS suite, repeated audio/fragment/performance regressions, BitFoundation tests, strict lint and dead-code analysis, universal iOS Release builds, and iOS/macOS archives.
