Every so often a batch came up one short. Not always, just sometimes, and only ever by exactly one. A hundred records went in, ninety-nine came out, and the missing one was always the last in the batch. Tidy bugs are the worst kind because they look deliberate.
The code was a pagination loop, the sort of thing you read a thousand times without reading at all. It walked offsets in steps of the page size and stopped when the offset reached the total. The condition was offset < total, the step was offset += pageSize, and when total happened to be an exact multiple of the page size everything was fine. When it wasn't, the final partial page sat just past the last full step, and the loop had already decided it was done. The last page never got fetched.
Two of us approved that pull request. I was one of them. We both read the loop, nodded at the offset arithmetic, and moved on, because off-by-one errors hide in exactly the place experienced eyes skim fastest: the boundary. You check that the loop starts right, you check the body, and you trust the termination because it "obviously" terminates. It did terminate. It just terminated one page early on a Tuesday with the wrong record count.
The fix was a single character, < became <= after I reworked the bound to count pages rather than chase offsets, plus a test that deliberately uses a total that isn't a multiple of the page size. That test is the real fix. The character was just where it surfaced. Now I always seed boundary tests with the awkward number, the one that's one more than a round multiple, because round numbers lie to you and your reviewers in perfect unison.