Timing bounds sit between the deadline and the body, not close to either

[Shashankss1205]

Closes #40.

What was actually flaking

Not the deadline machinery — the assertions about it. Each of the five tests bounds how long an interrupted node took, and every bound was a hand-picked constant sitting close to the deadline. < 2.0 on a 0.2s deadline leaves 1.8s of room; a 2-3× scheduling delay under contention eats that, and the test answers a question about machine load instead of about the guard.

The change

Every bound now sits between the deadline and the uninterrupted body, with seconds of slack on both sides:

test	deadline	body	was	now
syscall interrupt	0.2s	5s	< 2.0	< 3.0
fan-out worker	1.5s	5s → 15s	< 3.0	< 6.0
unreachable ceiling	0.2s	2s → 10s	< 1.0	< 4.0
agent wall clock	0.5s	30s	< 10	< 15
cookbook nap	0.25s	5s	< 1.0	< 3.0

Two bodies were lengthened rather than their bounds widened, because there was no room to put a bound inside the gap. An uninterrupted body only ever runs its full length when the test is failing, so lengthening one costs nothing on the green path and widens the signal the assertion reads.

The unreachable-ceiling test grew a second body: its two runs want opposite things from one. The first must run to completion (so it wants to be short — now 0.05s, down from 2.0s, which makes this test faster) and the second must be cut off (so it wants to be long — now 10s).

The cookbook page's own numbers are untouched. Budget(max_seconds=0.25) and time.sleep(5.0) are what the page prints and what tests/test_cookbook_basics.py exists to run verbatim. Only the test's own elapsed bound moved.

Verification

• 20/20 consecutive runs of all five, with 3 full pytest suites and 30 CPU spinners on the same 20-core box, at load average 33–35.
• The bounds have not gone vacuous: reverting the exit check in deadline_guard (if state["fired"] or (left is not None and left <= 0)) turns four tests in test_budget_enforcement.py red, and restoring it turns them green.
• uv run pytest full suite green; uv run ruff check grapharc tests clean.

Honest limit

The original flake did not reproduce here. The old bounds also passed 8/8 under that same load. So this removes the mechanism by which a scheduling delay could flip these assertions — it does not turn an observed red green. The issue's reproduction was three suites in separate worktrees with separate venvs, which is a different pressure shape (I/O and memory, not just CPU oversubscription) from what I could generate.

I took the issue's first option (widen the margins) rather than the marker/serialisation or loadavg-skip options, because it is the only one of the three that keeps the tests running everywhere and keeps the signal honest — a skip-under-load test proves nothing on exactly the machine most likely to be loaded, i.e. CI.

🤖 Generated with Claude Code