discourse/app/jobs/scheduled/heartbeat.rb

# frozen_string_literal: true

# This job is deprecated and will be removed in the future. The only reason it exists is for clean up purposes.
module Jobs
  # used to ensure at least 1 sidekiq is running correctly
  class Heartbeat < ::Jobs::Scheduled
    every 24.hours

    def execute(args)
      ::Jobs.enqueue(:run_heartbeat, {})
    end
  end
end
DEV: enable frozen string literal on all files This reduces chances of errors where consumers of strings mutate inputs and reduces memory usage of the app. Test suite passes now, but there may be some stuff left, so we will run a few sites on a branch prior to merging 2019-05-02 18:17:27 -04:00			`# frozen_string_literal: true`

FIX: Redo Sidekiq monitoring to restart stuck sidekiq processes (#30198) This commit reimplements how we monitor Sidekiq processes that are forked from the Unicorn master process. Prior to this change, we rely on `Jobs::Heartbeat` to enqueue a `Jobs::RunHeartbeat` job every 3 minutes. The `Jobs::RunHeartbeat` job then sets a Redis key with a timestamp. In the Unicorn master process, we then fetch the timestamp that has been set by the job from Redis every 30 minutes. If the timestamp has not been updated for more than 30 minutes, we restart the Sidekiq process. The fundamental flaw with this approach is that it fails to consider deployments with multiple hosts and multiple Sidekiq processes. A sidekiq process on a host may be in a bad state but the heartbeat check will not restart the process because the `Jobs::RunHeartbeat` job is still being executed by the working Sidekiq processes on other hosts. In order to properly ensure that stuck Sidekiq processs are restarted, we now rely on the [Sidekiq::ProcessSet](https://github.com/sidekiq/sidekiq/wiki/API#processes) API that is supported by Sidekiq. The API provides us with "near real-time (updated every 5 sec) info about the current set of Sidekiq processes running". The API provides useful information like the hostname, pid and also when Sidekiq last did its own heartbeat check. With that information, we can easily determine if a Sidekiq process needs to be restarted from the Unicorn master process. 2024-12-17 23:48:50 -05:00			`# This job is deprecated and will be removed in the future. The only reason it exists is for clean up purposes.`
FEATURE: unicorn sidekiq will restart sidekiq on complete failure. (checks every 30 minutes for complete failure) 2014-04-22 23:13:18 -04:00			`module Jobs`
			`# used to ensure at least 1 sidekiq is running correctly`
DEV: Upgrading Discourse to Zeitwerk (#8098) Zeitwerk simplifies working with dependencies in dev and makes it easier reloading class chains. We no longer need to use Rails "require_dependency" anywhere and instead can just use standard Ruby patterns to require files. This is a far reaching change and we expect some followups here. 2019-10-02 00:01:53 -04:00			`class Heartbeat < ::Jobs::Scheduled`
FIX: Redo Sidekiq monitoring to restart stuck sidekiq processes (#30198) This commit reimplements how we monitor Sidekiq processes that are forked from the Unicorn master process. Prior to this change, we rely on `Jobs::Heartbeat` to enqueue a `Jobs::RunHeartbeat` job every 3 minutes. The `Jobs::RunHeartbeat` job then sets a Redis key with a timestamp. In the Unicorn master process, we then fetch the timestamp that has been set by the job from Redis every 30 minutes. If the timestamp has not been updated for more than 30 minutes, we restart the Sidekiq process. The fundamental flaw with this approach is that it fails to consider deployments with multiple hosts and multiple Sidekiq processes. A sidekiq process on a host may be in a bad state but the heartbeat check will not restart the process because the `Jobs::RunHeartbeat` job is still being executed by the working Sidekiq processes on other hosts. In order to properly ensure that stuck Sidekiq processs are restarted, we now rely on the [Sidekiq::ProcessSet](https://github.com/sidekiq/sidekiq/wiki/API#processes) API that is supported by Sidekiq. The API provides us with "near real-time (updated every 5 sec) info about the current set of Sidekiq processes running". The API provides useful information like the hostname, pid and also when Sidekiq last did its own heartbeat check. With that information, we can easily determine if a Sidekiq process needs to be restarted from the Unicorn master process. 2024-12-17 23:48:50 -05:00			`every 24.hours`
FEATURE: unicorn sidekiq will restart sidekiq on complete failure. (checks every 30 minutes for complete failure) 2014-04-22 23:13:18 -04:00
			`def execute(args)`
FIX: Zeitwerk-related fixes for jobs. (#8187) 2019-10-14 06:03:22 -04:00			`::Jobs.enqueue(:run_heartbeat, {})`
FEATURE: unicorn sidekiq will restart sidekiq on complete failure. (checks every 30 minutes for complete failure) 2014-04-22 23:13:18 -04:00			`end`
			`end`
			`end`