The 39 rows that vanished at per_page=100, and the 277 refusals that never raised

`except Exception: bad += 1` compiles, runs and reports. What it does not do is tell a claim about the item apart from a claim about the wire. The 277 responses that came back as two words of plain text where JSON was expected ^[4] were not entries lacking bodies, they were entries the server declined to serve that second, and the handler filed them as the first thing ^[5]. That is 67 percent of the corpus ^[1] going into a counter.

The printed table did disclose it. Coverage sat at 32.5 percent in the column next to the answer ^[6]. Both figures were printed with equal confidence and only one was read. The gap to the real share was 5.4 points ^[7]. In the author's offline reproducer, against a fake server that refuses in bursts, the gap was smaller: 24.8 percent against a ground truth of 23.5 ^[9], an error of 1.3 points ^[4]. An error of that size survives review indefinitely. A sixty point error gets caught before lunch. The expensive failure mode is the one that lands inside the range you were already expecting.

The pagination half is stranger, and no assertion inside the pipeline could reach it. Walking the same endpoint with the same tag in the same minute, the author reports that per_page of 25, 75, 99, 101, 125, 150 and 200 all recovered 422 unique ids, while per_page=100 recovered 383 ^[11]. It also terminated politely, with an empty page 5 ^[12]. Those four pages held exactly 400 rows: 383 distinct ids, 17 of them served twice across pages 2 and 3, and 39 never served at all ^[13]. Anyone reconciling row count against pages times page size arrives at 400 and stops looking. The duplicates are paying for the absences.

That is 9.2 percent of the population gone ^[2], and not a random 9.2 percent. The 100-row walk reaches back only to 2026-07-14 where the full listing continues to 2026-06-21 ^[14], so the hole is the oldest 23 days of entries ^[3]. Any statement about how the challenge developed over time is drawn from the part that was missing.

The author says he found this only after handing the code to Gemini and asking what could still truncate the dataset beneath his completeness check; the first-ranked answer was that the check validates the fetched set against the listing and says nothing about the listing itself ^[10]. The strict collector he wrote retries unresolved ids, slows down on refusal, and raises rather than returns when anything is still missing. At 0.45s between requests doubling to a 2s ceiling, it resolved all 277 in four rounds: 134, then 77, then 63, then 3 ^[8]. One id never resolved and turned out to be a genuine 404, an entry deleted between the listing call and the fetch, so resolved-as-404 is permitted alongside parsed [c8b].

Absent versus unavailable is not a fine distinction here. It is the entire content of the number.