mirror of
https://github.com/discourse/discourse.git
synced 2024-12-27 22:04:35 +08:00
0d1d707213
What is the problem? When an admin changes the default_sidebar_categories or default_sidebar_tags site settings and opts to backfill the setting, we currently enqueue a sidekiq job to run the backfilling operation. When an admin changes those settings multiple times within a short time frame, multiple sidekiq jobs with different backfilling parameters will be enqueued. This is problematic if multiple jobs are executed concurrently as it may lead to situations where a job with “outdated” site setting values is completed after a job with the “latest” site setting values. What is the fix? By setting `cluster_concurrency` to `1`, we ensure that only one of such backfilling job will execute across all the sidekiq processes that are deployed at any point in time. Since Sidekiq pops off job in the order in which they are pushed, limiting the cluster concurrency here will allow us to execute the enqueued `Jobs::BackfillSidebarSiteSettings` jobs serially.
16 lines
439 B
Ruby
16 lines
439 B
Ruby
# frozen_string_literal: true
|
|
|
|
class Jobs::BackfillSidebarSiteSettings < Jobs::Base
|
|
# There should only be one of these jobs running at a time and it will be ordered based on the order in which the job
|
|
# was enqueued.
|
|
cluster_concurrency 1
|
|
|
|
def execute(args)
|
|
SidebarSiteSettingsBackfiller.new(
|
|
args[:setting_name],
|
|
previous_value: args[:previous_value],
|
|
new_value: args[:new_value],
|
|
).backfill!
|
|
end
|
|
end
|