DEV Community: Fabio Bazurto Blacio

Pagination: Always a "sort" (of) mistake [bugfix]

Fabio Bazurto Blacio — Mon, 22 Jun 2026 03:13:39 +0000

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

Rails 7.1
Ruby 3.2.x
Kaminari gem 1.2

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

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

The two returning values in Action Mailer [bugfix]

Fabio Bazurto Blacio — Mon, 09 Feb 2026 05:04:34 +0000

Background

Rails 7.1
Ruby 3.x

Your production environment is sending emails using Action Mailer and smtp delivery method. You implemented a very common pattern using Action:

class NotificationMailer < ApplicationMailer
  def processed_success(user:)
    if user.pass_custom_condition?
      mail(to: user.email, subject: 'Record processed')
    else
      Rails.logger.info('Record processed but notification is not delivered')
    end
  end
end

Inside the Mailer, there is a condition that will return two possible values: a fully configured mail object and automatically is returned a nullable object ActionMailer::Base::MailNull.

The Iteration

An iteration that implements dynamic delivery settings.[1]

class NotificationMailer < ApplicationMailer
  include Customizable # concern to apply changes from db 

  def processed_success(user:)
    if user.pass_custom_condition?
      mail(to: user.email, subject: 'Record processed')
    else
      Rails.logger.info('Record processed but notification is not delivered')
    end
  end
end

Concern

module Customizable
  extend ActiveSupport::Concern

  included do # include callback into the mailers
    after_action :overrides_mail_settings, if: has_overrides_enabled?
  end

  def overrides_mail_settings
    mail.delivery_method.settings.merge!(@business.smtp_settings)
  end

  def has_overrides_enabled?
    @business.customize.present?
  end
end

The Bug

Following the suggested implementation in the rails documentation and the backward common pattern, you should receive this error when you try to deliver NotificationMailer#deliver_now

[ArgumentError] SMTP To address may not be blank: []

Before the callback change, the mailing process finishes with a return value: Mail::Message or ActionMailer::Base::MailNull.
After adding the callback, the mailer lifecycle expands with a message object copying default values into it.

Solution

Our goal is ensuring backward compatibility by returning: Mail::Message or ActionMailer::Base::MailNull.

Concern

module Customizable
  extend ActiveSupport::Concern

  included do # include callback into the mailers
    after_action :overrides_mail_settings, if: overrides_allowed?
  end

  def overrides_mail_settings
    mail.delivery_method.settings.merge!(@business.smtp_settings)
  end

  def overrides_allowed?
    @business.customize.present? && message.to.present?
  end
end

Final Words

Although this fixes our problem and ensures backward compatibility, I would rather move business validation out of the mailer. In my opinion, a mailer class is in the presentation layer responsible for configuring delivery details, customizing layouts and showing content. Any business rule should be in a different component like a service or job.

Bibliography

Action Mailer Basics — Ruby on Rails Guides. (2024). Ruby on Rails Guides. https://guides.rubyonrails.org/action_mailer_basics.html
Rails Api. (2025). rails/actionmailer/lib/action_mailer/base.rb at main · rails/rails. GitHub. https://github.com/rails/rails/blob/main/actionmailer/lib/action_mailer/base.rb

‌

Bug: Docker-compose up?

Fabio Bazurto Blacio — Tue, 04 Jun 2024 00:56:05 +0000

ERROR

I've been using a bash script to do docker operations in past by using docker-compose. So one day, I started to receive this error:

**ERROR: for my_docker_container_1 'ContainerConfig'**

CAUSE

The statement docker-compose is not working anymore for recent versions of Docker Compose. This error is very common when you have updated to the latest version of Docker Compose ( I'm 2.27.0). Docker Compose syntax changed.

docker-compose up -d my_docker_container

SOLUTION

In order to start/stop containers you will need to remove "-" and run command like this.

docker compose up -d my_docker_container