mirror of
https://github.com/discourse/discourse.git
synced 2024-11-29 22:24:24 +08:00
a72dc2f420
Previously, problem checks were all added as either class methods or blocks in AdminDashboardData. Another set of class methods were used to add and run problem checks. As of this PR, problem checks are promoted to first-class citizens. Each problem check receives their own class. This class of course contains the implementation for running the check, but also configuration items like retry strategies (for scheduled checks.) In addition, the parent class ProblemCheck also serves as a registry for checks. For example we can get a list of all existing check classes through ProblemCheck.checks, or just the ones running on a schedule through ProblemCheck.scheduled. After this refactor, the task of adding a new check is significantly simplified. You add a class that inherits ProblemCheck, you implement it, add a test, and you're good to go.
23 lines
723 B
Ruby
23 lines
723 B
Ruby
# frozen_string_literal: true
|
|
|
|
module Jobs
|
|
# This job runs all of the scheduled problem checks for the admin dashboard
|
|
# on a regular basis. To add a problem check, add a new class that inherits
|
|
# the `ProblemCheck` base class.
|
|
class ProblemChecks < ::Jobs::Scheduled
|
|
sidekiq_options retry: false
|
|
|
|
every 10.minutes
|
|
|
|
def execute(_args)
|
|
# This way if the problems have been solved in the meantime, then they will
|
|
# not be re-added by the relevant checker, and will be cleared.
|
|
AdminDashboardData.clear_found_scheduled_check_problems
|
|
|
|
::ProblemCheck.scheduled.each do |check|
|
|
Jobs.enqueue(:problem_check, check_identifier: check.identifier.to_s)
|
|
end
|
|
end
|
|
end
|
|
end
|