[JacobStephens2]

Summary

The test harness now polls CI every 100ms, not every 10ms. The grace period stays at 300ms. No product change.

 // tests/support/mod.rs, Scenario::command
 .env("THIRDSHIFT_CI_GRACE_MS", "300")
-.env("THIRDSHIFT_POLL_MS", "10");
+.env("THIRDSHIFT_POLL_MS", "100");

The comment above that line now says why 100ms was chosen. The comment in tests/ci.rs on the mergeability countdown (it needs a fourth read and overrides the grace period to 5000ms) is updated to match the new interval.

What this buys: very little under load. Each read starts the Python fake gh, and one start costs 0.07–0.17s wall here. So polls were already paced by process startup, not by the 10ms sleep. I added a counter to the fake to count its starts (not committed):

Fake gh starts	10ms	100ms
ci binary	242	243
merge_run binary	515	517
no_checks_within_the_grace_period alone (3 runs)	11, 11, 11	9, 9, 9
a_pr_whose_mergeability_stays_unknown alone (3 runs)	13, 13, 13	12, 13, 15

Only the scenarios bounded by the grace period save anything, about 2 reads each. On an idle machine, where a start is cheaper, the saving would be larger. 50ms, 100ms and 200ms all passed and gave about the same counts, so I used the ticket's suggested 100ms. The measurements don't favour one over the others.

The same states are still tested.

• Still running (pending_polls) and the mergeability countdown (unknown_polls) count reads, not time.
• Checks that appear through on-ci-read hooks show up on the first read.
• poll::within always probes at least once before checking the deadline, so the absent and stays-unknown paths still fire.

Evidence

Same machine: 4 cores, rustc 1.98.1. Other Runs were active the whole time, and the load was not steady (mean 1-minute load noted). The wall times are not comparable across rows; user + sys is the meaningful column.

Warm full cargo test	Wall	User + sys	Load (mean / max)
#174 baseline (on #174)	268s	479 + 222 = 701s	5.07 / 5.78
Before (10ms, this branch's base)	746s	482 + 219 = 701s	16.60 / 19.68
After (100ms)	491s	469 + 217 = 686s	10.99 / 13.60

CI-heavy binary	Before wall	Before user + sys	After wall	After user + sys
ci	26.2s	25.8 + 10.1 = 35.9s	32.4s	23.3 + 9.0 = 32.3s
merge_run	68.7s	57.1 + 25.8 = 82.9s	73.9s	57.1 + 25.3 = 82.4s
spec_run	205.3s	213.0 + 81.4 = 294.4s	207.7s	201.8 + 75.9 = 277.7s

The per-binary loads were about 11–13 before and 13–15 after. ci and merge_run got slower in wall time while their CPU held or dropped. That fits both noisy load and the longer sleep between reads when checks are pending. A second ci run at 100ms took 24.3s wall and 24.1 + 9.5s. User + sys fell by about 2% overall. This lever does little toward #174's "half the CPU" target: the cost is in starting processes, not in how often the harness polls.

• After: full cargo test passes: 432 tests, 0 failures, across 24 test binaries.

Merge Danger

Door: two-way

Revert the one value.

Blast Radius: test-harness

Only the test harness's CI poll interval changes. Scenarios that wait on pending checks now sleep 100ms between reads instead of 10ms.

Unaddressed findings

Standards

None.

Spec

None. The spec review's findings (the process count barely moves under load, 100ms isn't favoured by the measurements, the loads aren't comparable, ci's wall time went up) are reported above rather than hidden.

Closes #204

🤖 Generated with Claude Code