Task-List Pagination Integrity Automation: When a Database's Own Row Ceiling Hides Data Behind a 200 OK

A single query with no explicit pagination looks completely correct in every test performed against a smaller dataset — it returns exactly what's asked for, with a normal success response, because the actual row count never gets anywhere near whatever hidden ceiling the underlying database platform enforces. The defect has no failure mode that looks like a failure: no error, no partial-content status code, nothing distinguishing a complete result from a truncated one. It only becomes visible once a real organization's data volume crosses that ceiling — and by then, the missing data has already been silently missing for however long it took to get there.

A managed database platform enforcing a maximum row count per request is a reasonable, common safeguard against a single runaway query consuming unbounded resources — the platform, not the application, decides how many rows a single request can return, and that ceiling applies regardless of how the request itself was written. A single, unpaginated fetch built without an explicit page/range strategy isn't wrong when it's written — it's incomplete in a way that costs nothing to ignore until the data volume it's pointed at happens to grow past the platform's own ceiling, at which point the exact same code silently starts returning less than it asks for, with no code change required to trigger it.

The defect was found by direct production measurement, not a code review guess: at the agency running the check, the organization had 1,607 tasks in total, and the single unpaginated request was silently returning only the first 1,000 of them — 607 tasks, comprising 463 completed and 12 still active, never reached the browser at all. Because the underlying query orders tasks by delivery date descending, the row ceiling always consumed the oldest tail of the list first: a "Completed Tasks" tab was displaying a partial slice of the organization's actual history while presenting itself as the complete record, and any task older than the silent cutoff simply did not exist as far as any search or filter in the product could tell — not slow to find, genuinely unreachable.

The root mechanism is specific to the database platform itself, not a bug in the application's own query logic: Supabase's PostgREST layer enforces its own `max-rows` setting (1,000 by default) that overrides any larger request automatically — the response still comes back as a completely normal, successful HTTP 200, with the row count simply capped and nothing in the response body or status code distinguishing a capped result from a genuinely complete one. A query written to ask for everything in one call has no way to detect this on its own; it looks identical whether the real total is 900 rows or 900,000.

The fix replaces the single request with a loop that requests successive pages of up to 1,000 rows each, using the database layer's own range mechanism to specify which slice of rows each request should return, continuing until a page comes back with fewer rows than the requested page size — the only reliable signal that nothing is left to fetch, since a full page could always mean there's more. An explicit ceiling stops the loop at 50 pages, a deliberate limit of 50,000 tasks per organization: the code comment accompanying it is direct about the reasoning — if an organization's task count ever gets that large, that scale is a different problem to solve deliberately, and a task list screen silently trying to load an unbounded number of rows forever is not where that problem should be discovered. Hitting that ceiling logs a specific warning rather than failing silently or looping without end.

Someone searches for a specific task they know was completed several months earlier, in an organization with well over a thousand total tasks. Before the fix, that task simply wasn't present in the data the browser ever received — the search wasn't broken, the data behind it was silently incomplete. After the fix, the same task is retrievable, because the full task history is paged through completely rather than cut off at the platform's row ceiling.

A task list, once an organization's history is large enough to have silently hit the platform's row ceiling, actually returns everything it claims to — a "Completed" tab that says complete now genuinely is, and a search for an older task can actually find it. And because the defect had no visible failure symptom (a normal 200 response, no error, no obviously wrong count for a smaller organization), the value here specifically is closing a class of defect that data volume alone would otherwise have kept hidden indefinitely for a smaller organization and silently active for a larger one.

An organization with a task volume nowhere near the underlying 1,000-row ceiling was never actually affected by this specific defect — the fix's value is proportional to how close an organization's real task count sits to (or past) that ceiling. This is also not a general performance or infinite-scroll feature; the safety ceiling at 50,000 tasks is a deliberate stop, not a claim that Run is built to smoothly browse an unbounded task list of any size.

A single request that returns a normal success response looks complete by every visible signal available to the calling code — there is no error to catch, because nothing about the request actually failed from the database platform's own point of view. Centriu Run's fix doesn't trust that signal; it keeps requesting successive pages specifically until a page smaller than full proves there's genuinely nothing left, treating "the response looked successful" and "the response was complete" as two different claims that need two different checks.