Note

The pagination bug that silently drops your oldest records.

It passes the type checker. It passes the build. Nothing in the interface looks wrong. Only counting the answer catches it.

This is a specific bug with a specific shape, and once you have seen it you will find it in other people's code for the rest of your career.

The shape

A paginated fetch loop usually terminates the same way: request a page of N rows, and if fewer than N come back, you have reached the end.

Now suppose the page size is two thousand and the database caps every response at one thousand rows. The first request asks for two thousand and receives one thousand. One thousand is fewer than two thousand. The loop concludes it has reached the end, and returns.

Every query silently stops at row one thousand. No error, no warning, no truncation flag. The function returns successfully with a third of the data.

Why it is worse than it sounds

A random third missing would be survivable. What you actually lose is determined by your sort order — and almost every query is ordered by date descending, because that is what a human wants to see.

So the records dropped are the oldest ones. In a professional service firm, the oldest matters are the completed ones — the only matters whose full cost is actually known. Every average computed this way is biased toward newer, less-complete, less-billed work.

One page in a real system reported 999 matters where 1,673 matched. The number 999 looked plausible. Nobody questioned it for months.

Why nothing catches it

How to find it in your own systems

Find every paginated fetch and compare the page size against the platform's documented maximum response size. If the page size is larger, the loop is broken. If they are equal, the loop works but is one request from breaking when someone raises the constant.

Then make it structural: define the cap once, as a named constant carrying the reason, and derive page sizes from it. And write one check that runs against real data and asserts a count you verified by hand — the only kind of test that catches this class of failure.

Anything that reports a number should be able to tell you how many records the number came from. If it cannot, you are trusting an aggregate you cannot audit.