fix: Optimize message reindexing to reduce sidekiq job creation (#12618)
Changes searchkick callback behavior to check `should_index?` before creating reindex jobs, preventing unnecessary job creation for messages that don't need indexing (activity messages, unpaid accounts, etc.). Previously, `callbacks: :async` created reindex jobs for all messages (~5,100/min or 7.3M/day in production), which were then filtered by `should_index?` inside the job worker - resulting in 98% wasted jobs, Redis memory pressure, and avoidable p0 alerts. Now, `should_index?` is checked before job creation via `after_commit` callback, reducing job creation to actual incoming/outgoing messages from paid accounts. Changes: - Disable automatic searchkick callbacks - Add manual `after_commit` callback with `should_index?` condition - Add specs to verify callback behavior Expected impact: - 98% reduction in sidekiq job creation (~7.3M → ~150K jobs/day) - Reduced redis memory usage - Same async indexing behavior for eligible messages
This commit is contained in:
@@ -39,7 +39,7 @@
|
||||
#
|
||||
|
||||
class Message < ApplicationRecord
|
||||
searchkick callbacks: :async if ChatwootApp.advanced_search_allowed?
|
||||
searchkick callbacks: false if ChatwootApp.advanced_search_allowed?
|
||||
|
||||
include MessageFilterHelpers
|
||||
include Liquidable
|
||||
@@ -135,6 +135,7 @@ class Message < ApplicationRecord
|
||||
after_create_commit :execute_after_create_commit_callbacks
|
||||
|
||||
after_update_commit :dispatch_update_event
|
||||
after_commit :reindex_for_search, if: :should_index?, on: [:create, :update]
|
||||
|
||||
def channel_token
|
||||
@token ||= inbox.channel.try(:page_access_token)
|
||||
@@ -436,6 +437,10 @@ class Message < ApplicationRecord
|
||||
conversation.update_columns(last_activity_at: created_at)
|
||||
# rubocop:enable Rails/SkipsModelValidations
|
||||
end
|
||||
|
||||
def reindex_for_search
|
||||
reindex(mode: :async)
|
||||
end
|
||||
end
|
||||
|
||||
Message.prepend_mod_with('Message')
|
||||
|
||||
Reference in New Issue
Block a user