A Customer Vanishes Between Page One and Page Two

The sales team has a strange complaint about its customer dashboard. An account they saw a minute ago is missing, and another customer appears twice.

The developer checks the database. A database check confirms that neither account is missing. The next step is to trace which records it sends to the dashboard.

Nobody can reproduce the problem consistently until someone tries the same search during a busy part of the day.

New customer accounts are arriving while people browse the list.

The detail points toward the way the backend fetches records, rather than anything being wrong with the customer data itself.

The Problem Could Be in the Sort Order

Each request returns 25 customer records, with the newest accounts appearing first. The backend uses a database query to fetch each batch.

There is a catch: two customers can have the same creation timestamp. If the query sorts by that column, their relative order isn’t guaranteed.

Consider two customers created at the same time, with one appearing at the end of page one. If the database returns tied records in another order on the next request, that customer could turn up on page two as well.

Start by adjusting the database query. You can add a unique field after the creation date in the ORDER BY clause. 

It is worth testing this with several accounts that share the same timestamp. A dataset of neatly spaced sample records may never expose the issue.

New Customers Can Change the Next Page

The sort order might be stable, yet the sales team’s complaint can persist.

Here’s a more realistic example. A representative opens the first page, which contains the 25 newest customers. Five new accounts arrive before they click Next.

With offset pagination, the second request still skips 25 records. The five new accounts change the positions of the existing records. When the representative requests the next 25 rows, some customers may have moved into a different position. Same customer may then show up twice.

The problem is easier to spot when the dataset keeps changing.

Cursor pagination has a different approach. Next query uses that position to find the following records instead of skipping a fixed number of rows. The query then fetches records beyond that position.

Changing pagination methods isn’t always necessary. A relatively quiet admin panel may work perfectly well with offsets. The first step is to establish whether changing data is actually causing the complaint. New customer entries are less likely to shift the page boundary, provided the cursor uses a stable sort order.

Don’t Debug This From the Table Alone

The next time someone reports a missing customer, inspect the page requests in DevTools. Compare the IDs returned for page one and page two. Names alone aren’t enough to establish whether the same record appears twice.

If an ID appears in both responses, inspect the query and its sorting conditions. Inspect how React processes and renders the returned records.

Check the request parameters as well. A frontend sending page numbers from zero while the backend expects them to start at one can produce an entirely different set of results.

Reproducing the problem in a test environment is useful, but don’t test only with static data. Add records between page requests and see what changes.

A Node.js Development Agency in India should be able to trace this kind of issue from an API request down to its database query. When evaluating a Node.js web development company in India, ask how it tests customer lists while records are being added, rather than relying only on a fixed test dataset.

A successful API response tells you the request worked. It doesn’t tell you that the customer ended up on the page where someone expected to find them.