Pagination is a key component on web-applications that let users navigate through pages making easy to read/find records. Also, pagination is a great strategy to improve performance by avoiding to load entire dataset at once. However, while working with Kaminari, a popular pagination gem in Rails, I encountered an unexpected issue that revealed an interesting edge case.
Identify the issue
Basically, pagination in frontend was not working properly. Datatable should load 316 total rows, although when the user started to load 15 records per page, frontend is showing inaccurate total rows. Multiple of 15 should ends at 0 or 5. There were pages with 64 records, crazy world. Some pages were loading 12 or 11 rows. There is no issues or error messages in the frontend or backend.
Lost in debugging-land
After discarding Angular frontend errors, I started to dig into backend controller and Kaminari configuration. Nothing seems wrong. Everything looked good: test suite, smoke tests, desktop debugging. Despite of test results, I started to wonder: what if returned-data is wrong after all?
and... Bingo!
Finally, after checking every response I noticed that there were duped records in two different pages(pagination requests). Those duped records were skipped from Angular data-table and that's why loaded/total rows did not match.
Bingo: a sort of mistake
This tricky bug has a simple explanation: bad sorting.
Kaminari uses a SQL query using LIMIT/OFFSET strategy:
SELECT * FROM posts ORDER BY id LIMIT 25 OFFSET 0
ORDER BY: sort the collection.
LIMIT: number of records per page.
OFFSET: is used to skip a specified number of rows before starting to return rows from a query.
This works perfectly using ORDER BY id because primary key is unique. Check table A.
| id | title | body | created_at | lock |
|---|---|---|---|---|
| 101 | Welcome to the Platform | First post introducing the new platform features. | 2026-06-16 08:15:22 | false |
| 102 | Summer Update | Announcing the latest improvements and updates. | 2026-06-16 08:15:22 | true |
| 103 | Community Guidelines | Please review the rules and guidelines for posting. | 2026-06-16 08:15:22 | false |
| 104 | New Project Launch | Details about the upcoming project release. | 2026-06-16 08:15:22 | false |
| 105 | Maintenance Notice | Scheduled maintenance will happen this weekend. | 2026-06-16 08:15:22 | true |
table A - Posts table with same created_at value.
But when you use a column like created_at, with exactly same value, you let MySQL choose what records returns in a relative page. It only guarantees that all five rows appear together relative to other timestamps. It does not guarantee whether they appear as:
101,102,103,104,105
or
103,105,101,104,102
or any other order.
As a result:
Page 1 might end with rows 101,102,103
Page 2 might start with 103,104,105
because MySQL reordered the tied rows between executions.
Given created_at had exactly same values, I just added a secondary sort with a unique value id. You could use any other column to assign an unique position in the sorting, just check your indexes and choose a good column.
@posts = Post.order(created_at: :desc, id: :desc).page(params[:page]).per(20)
Conclusion
Pagination is an important tool for finding records—it keeps your listings fast and your users happy by avoiding that painful full-table load. So take care of your data structures and plan your sorting thoughtfully. Kaminari does what you configure, so make sure you're giving it the right instructions. Care for your dataset, plan what you show, and your users will be happy with your listing.
Bibliography
Stroz, S. (2025, October 14). MySQL basics: Turning the page—Using LIMIT and OFFSET for pagination. The Oracle MySQL Blog. Retrieved June 11, 2026, from https://blogs.oracle.com/mysql/mysql-basics-pagination
Dhandala, N. (2025, July 2). How to Implement Pagination with Kaminari in Rails. OneUptime | One Complete Observability Platform. https://oneuptime.com/blog/post/2025-07-02-rails-kaminari-pagination/view