What broke

Two clients decide whether a pull request may merge by reading its full review history: the command-line tool an agent runs, and the scheduled job that merges approved changes on weekdays. Both were repaired earlier the same day to page through that history instead of reading one truncated request.

Paging carries its own hazard, so both repairs put a bound on the walk: read at most twenty pages of fifty reviews, a thousand reviews, far past anything this forge has seen. Reaching the bound was treated as a failed read: a record the client could not finish reading is one it cannot vouch for, and the merge was refused with a sentence saying the record was too long to read in full.

The walk ended when a page came back shorter than the page size. That test has a hole at exactly one value. A record of exactly a thousand reviews arrives as twenty full pages, so the loop ends at the bound, and the client then reports that the record could not be read, about a record it has just read in full.

The belief was that a full last page means the record continues past the bound. It means only that the page was full.

How it showed

Nothing failed in service: the busiest pull request on this forge carries seven reviews, so no record comes near a thousand. The defect was found by reading the loop after it was written, and the error is arithmetic rather than a measurement on a live request:

twenty pages of fifty reviews = 1000 reviews a record of exactly 1000 = twenty full pages, no short page to stop on the walk ends at the bound -> "could not be read in full"

So the client refused a merge on the strength of a sentence that was false about its own data, which is worse than the failure it was guarding against: the refusal sends a reader to look for a truncation that did not happen.

What was watching

The paging repair that merged eleven minutes earlier had tests for the two directions that mattered then: an approval on a later page is found, a refusal on a later page still blocks, and an endless record fails closed. All three pass with a walk that stops on a short page or on the bound.

None of them filled the last page exactly. TestAnEndlessReviewRecordFailsClosed serves every page full, which exercises the bound only in its "more exists" form; a record that ends precisely there was not a case anyone wrote, because the number that exposes it is the product of two constants rather than anything observed.

The detecting sensor was a person reading the new loop, not a test and not a merge going wrong.

Where it sits

This is an invariants case with a boundary-sensor gap.

The family is invariants because the exit condition of the walk, "a short page means the end", is false at one point of its domain, and the client's decision rests on it being true everywhere. It is test-effectiveness because the tests around the bound covered one side of it.

Boundary sensors are the instrument this needed: not a device on the box but the practice of testing at the values where a rule changes behaviour. Here that value is the bound itself, and the suite had the value one above it and neither the value itself nor one below. Contract tests were present for the read and silent about the exit condition.

A code review could catch this, and did, but review is the sensor that fires last and least reliably: the same loop passed review eleven minutes earlier with the paging change that introduced it.

What we did

Both readers now ask one page beyond the bound. If that page comes back empty, the record ended at the bound and the walk returns what it read; if anything comes back, the record continues and the refusal stands. One extra request answers the question the bound could not, and the answer is about the data rather than about the page size.

The merge job's per-page read became one function, so its walk and its lookahead cannot drift apart. The command-line tool did not get that refactor: its walk and its lookahead are two inline calls with duplicated option literals that differ only in the page number, so there is a place for them to drift.

What now fails loudly

TestARecordEndingAtTheBoundIsReadInFull serves exactly twenty full pages and an empty one after them, and requires the merge to proceed on the verdict it found. The merge job's suite has the same test against its own fake forge (test_a_record_ending_exactly_at_the_bound_is_read_in_full), so both clients carry the assertion rather than one borrowing the other's.

The endless-record test still fails closed, so the bound keeps its purpose: more pages than this answers "the record continues", and the refusal stands with a reason a reader can check.

The gap that remains is general and worth naming, and it is narrower than "the tests are brittle": both suites build their fixtures from the constants, so a bound that moves to twenty-five moves both exact-multiple tests with it and nothing is re-derived by hand. What is not guarded is the next walk written without that fixture shape. Any walk whose exit condition is "fewer results than a page" has this hole at every exact multiple of the page size, and the only thing that catches it is a test whose fixture fills the last page exactly.