ActiveAdmin批量删除后PgSearch索引不同步的生产环境解决方案咨询

Got it, let's solve this problem once and for all. The root cause here is that ActiveAdmin's default bulk delete action often uses delete_all (which skips ActiveRecord callbacks) instead of destroy_all, and pg_search relies on those callbacks to keep its multisearch index in sync. Here are a few practical, production-ready solutions:

1. Override ActiveAdmin's Bulk Delete Action (Simple & Direct) #

The easiest way is to take control of the bulk delete process in your ActiveAdmin configuration for AcademicPaper, so you can explicitly update the search index after deletion.

Add this to your app/admin/academic_paper.rb:

ActiveAdmin.register AcademicPaper do
  # Override the default bulk destroy action
  batch_action :destroy, confirm: "Are you sure you want to delete these papers?" do |ids|
    # Delete the records (use destroy_all if you need callbacks for other logic too)
    AcademicPaper.where(id: ids).delete_all

    # Rebuild the pg_search multisearch index for AcademicPaper
    PgSearch::Multisearch.rebuild(AcademicPaper)

    # Redirect back with a confirmation message
    redirect_to collection_path, notice: "#{ids.count} papers deleted. Search index has been updated."
  end
end

This works great for most cases—especially if you're not dealing with thousands of records at once. The rebuild is immediate, so your search will be in sync right away.

2. Use destroy_all to Trigger PgSearch's Default Callbacks #

If you prefer to let pg_search handle the index updates automatically, make sure the bulk delete uses destroy_all instead of delete_all. destroy_all fires the after_destroy callback that pg_search uses to remove entries from the multisearch index.

Modify the batch action like this:

batch_action :destroy do |ids|
  # destroy_all triggers ActiveRecord callbacks, including pg_search's
  AcademicPaper.where(id: ids).destroy_all
  redirect_to collection_path, notice: "#{ids.count} papers deleted. Search index is up to date."
end

Note: This is slower than delete_all because it processes each record individually, so it's better for smaller batches. If you're deleting hundreds or thousands of records, the next option is better.

3. Offload Rebuild to a Background Job (For Large Datasets) #

For bulk operations that affect a lot of records, syncing the index during the request can cause timeouts. Use a background job (like Sidekiq or Delayed Job) to rebuild the index asynchronously.

First, create a background job:

# app/jobs/rebuild_pg_search_index_job.rb
class RebuildPgSearchIndexJob < ApplicationJob
  queue_as :default

  def perform(model_name)
    model_class = model_name.constantize
    PgSearch::Multisearch.rebuild(model_class)
  end
end

Then update your ActiveAdmin batch action to enqueue the job:

ActiveAdmin.register AcademicPaper do
  batch_action :destroy do |ids|
    AcademicPaper.where(id: ids).delete_all
    # Enqueue the job to rebuild the index in the background
    RebuildPgSearchIndexJob.perform_later("AcademicPaper")
    redirect_to collection_path, notice: "#{ids.count} papers deleted. Search index will be updated shortly."
  end
end

This keeps your web request fast, and users get immediate feedback while the index rebuilds in the background.

Bonus: Verify PgSearch Callback Setup #

Double-check that pg_search is properly configured to use callbacks for your model. Your AcademicPaper model should have something like this:

class AcademicPaper < ApplicationRecord
  include PgSearch::Model
  pg_search_scope :search_by_title_and_content, against: [:title, :content]
  multisearchable against: [:title, :content]
end

The multisearchable macro automatically adds the necessary after_save, after_destroy, and after_touch callbacks to keep the index in sync—so as long as your bulk operations trigger these callbacks (or you explicitly rebuild), you won't have sync issues.

内容的提问来源于stack exchange，提问作者Mahmoud Mousa Hamad