What broke

The station's agents merge pull requests through two clients. One is a command-line tool an agent runs by hand; the other is a scheduled job that merges approved changes on weekdays without anyone watching. Both read a pull request's reviews before deciding, because a merge is only allowed when the newest verdict on it is an approval. The reviews are the record of who said what about the change, in the order they said it.

Both clients asked for the record in a single request. The command-line tool asked for fifty at a time; the scheduled job asked for however many the server felt like returning, because it named neither a page nor a size.

A server that truncates a list does not truncate it from the front. This forge returns reviews oldest first and stops at its own page size, so one request returns the oldest reviews on the pull request. The newest verdicts are the ones that do not come back. The clients believed they had read the record and had read its beginning.

Both directions of the mistake are possible and both are bad. A refusal posted after the approval was missed, so the guard merged a change its reviewer had rejected. An approval posted after a refusal was missed too, so the guard refused a change that had been cleared and left it standing.

How it showed

Nothing failed in service. No pull request on this forge carries more than fifty reviews; the busiest carries seven, so both clients read every review they were asked about and their decisions on real changes were correct. The defect was found by measuring the server's answer, not by watching a merge go wrong.

Measured on this forge, the first two on 2026-11-01, the third on 2026-11-02:

/pulls/18/reviews -> review ids 72..78, ascending by submission /pulls/18/reviews?limit=3&page=3 -> 78, the newest review /repos/abrahms/ops/commits, no limit -> 30 rows of 32, the newest 30

The third line is a different endpoint on the same server, quoted because it shows the same rule from outside the reviews code: an unnamed page size is not "everything", it is the server's default. Which end it drops depends on the order the endpoint lists in. Reviews come back oldest first, so a truncated read loses the newest; commits come back newest first, so the same truncation loses the oldest. That is why "I read the list" was not an answer either client could act on.

What was watching

The command-line tool had tests for its merge guard, and they fed it one page of reviews. A test that serves a single page cannot tell a client that pages from a client that does not: the fake server answers the first request with the whole record either way. The scheduled job's tests had the same shape.

Neither client's tests said how many reviews a record holds, so neither had a reason to read past page one. The absence is one line of fixture, which is why it survived: a review record with a second page is not an edge case anyone writes down unless they have seen this server truncate something.

The detecting sensor was a person reading the guard against the server's own paging behaviour, an hour after the read was written.

Where it sits

This is a comprehension failure over an invariants gap.

The family is comprehension because the defect was in what the clients believed a list request returns, not in any arithmetic. It is invariants because the decision the guard makes requires a property, "the verdict I read is the newest one", and nothing established it.

Contract tests would have caught it: the contract that matters is not "a list of reviews comes back" but "a list comes back in this order and truncates at this point", and a test against a fake server that serves pages in that order asserts the whole thing. The suite had example-based tests of the guard's decision and none of the read's completeness.

A required "re-read before merging" or a retry would not help. This is a read that answers a different question than the one asked, and asking twice in the same way gets the same oldest page.

What we did

Both readers now page until a page comes back short. The page size is the server's maximum, fifty; the walk is bounded at twenty pages, a thousand reviews, far past anything this forge has seen; and reaching the bound is treated as a failed read rather than a pass, because a record the guard could not finish reading is one it cannot vouch for.

The two clients share the shape and not the code, so each got the change and each got its own tests.

What now fails loudly

Three assertions in the command-line tool's suite, and one of them is the inverse of the defect:

• TestAnApprovalOnALaterPageIsFound merges where the old read refused a head

that had in fact been re-approved.

• TestARefusalOnALaterPageStillBlocks refuses where the old read would have

merged past a fresh refusal.

• TestAnEndlessReviewRecordFailsClosed requires a server that answers every

page with a full one to fail the merge rather than permit it.

The scheduled job has the same three shapes against a fake server that serves named pages, so the walk can be seen asking for page two instead of being trusted to.

What is still not guarded is the server's own behaviour: the page order and the truncation are measured facts recorded in the code's comments, not contracts any test re-establishes against a real server. If a future version of the forge lists newest first, both readers still page to a short page and stay correct; if it stops truncating, they stay correct. The failure mode that would not be caught is a server that truncates from the other end.