good_job 4.14.2 → 4.16.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 0f0f62c12c0c19a4afd8f71d3dae19479ac4a7df6342ac399bf8e447fbbe8f5b
-  data.tar.gz: 75a2a8a282b0c28e370230397dfc5f1de470681b1d53cbb0dd6ee46384e87fe4
+  metadata.gz: 9b13d49cf0a8c78543c55426eaf82eafd8518bd6f9a22ab081ac1657ff129227
+  data.tar.gz: c8e21ac65881fa645409b00d496beff08b9f99cfbcefb832a01d29bcff2e760a
 SHA512:
-  metadata.gz: ba1a959622762c21e723f6d406d30d8fda81d736560f3c710a7c363d8206697d0eb856dbe9ee865a340ad4f3d8db5354a707f78d695d0221fe1779ba07709c7b
-  data.tar.gz: 0bb8d09ca31aefe0e6da18096da53f5fdfc7e7be820afb54791b051f7ea29464c730aefb9eaeffaeaaa5fa3a6f5e029d158651fde41bd8876fd280e3fcd4269a
+  metadata.gz: af467c3effc78f424155420005e79ffdbff6249ae7a02ef9084f94d81d8aa28920bcfbc71f46349f6e67597f73cf39f7f2f2cd7f4edd869084091e9ab962c951
+  data.tar.gz: 19732a4dbfa6c64aeddd85c721a82f94cbaf50f2e784fa04bf22d2321bb518723992535595cdcc32a172cefbb77476ea66c9e06182c640dc2dc62b0306bf2cae

data/CHANGELOG.md

@@ -1,5 +1,48 @@
 # Changelog
 
+## [v4.16.0](https://github.com/bensheldon/good_job/tree/v4.16.0) (2026-04-14)
+
+[Full Changelog](https://github.com/bensheldon/good_job/compare/v4.15.0...v4.16.0)
+
+**Implemented enhancements:**
+
+- Allow filtering by label on dashboard [\#1739](https://github.com/bensheldon/good_job/pull/1739) ([bensheldon](https://github.com/bensheldon))
+- Allow multiple concurrency rules per job via labels [\#1700](https://github.com/bensheldon/good_job/pull/1700) ([bscofield](https://github.com/bscofield))
+
+**Fixed bugs:**
+
+- Fix advisory lock connection stickiness in block contexts [\#1736](https://github.com/bensheldon/good_job/pull/1736) ([bensheldon](https://github.com/bensheldon))
+- Add JRuby 10 to testing matrix [\#1559](https://github.com/bensheldon/good_job/pull/1559) ([bensheldon](https://github.com/bensheldon))
+
+**Closed issues:**
+
+- Job duration misreported if interrupted [\#1723](https://github.com/bensheldon/good_job/issues/1723)
+
+**Merged pull requests:**
+
+- Use annotated git tag in release script [\#1741](https://github.com/bensheldon/good_job/pull/1741) ([bensheldon](https://github.com/bensheldon))
+- Double single-thread scheduler integration test timeout on JRuby [\#1738](https://github.com/bensheldon/good_job/pull/1738) ([bensheldon](https://github.com/bensheldon))
+- Fix JRuby test flakes for scheduler timeout and interrupted execution duration [\#1737](https://github.com/bensheldon/good_job/pull/1737) ([bensheldon](https://github.com/bensheldon))
+- Count Advisory Locks and refactor advisory lock lifecycle [\#1735](https://github.com/bensheldon/good_job/pull/1735) ([bensheldon](https://github.com/bensheldon))
+- Show interrupted execution recovery duration in dashboard [\#1733](https://github.com/bensheldon/good_job/pull/1733) ([bensheldon](https://github.com/bensheldon))
+- chore: use `merge` to avoid mutate the query object [\#1717](https://github.com/bensheldon/good_job/pull/1717) ([luizkowalski](https://github.com/luizkowalski))
+
+## [v4.15.0](https://github.com/bensheldon/good_job/tree/v4.15.0) (2026-04-09)
+
+[Full Changelog](https://github.com/bensheldon/good_job/compare/v4.14.2...v4.15.0)
+
+**Implemented enhancements:**
+
+- Add opt-in "FOR NO KEY UPDATE SKIP LOCKED" job lock strategy and hybrid strategy for online migration [\#1731](https://github.com/bensheldon/good_job/pull/1731) ([bensheldon](https://github.com/bensheldon))
+- Allow ordering by scheduled\_at instead of created\_at when dequeueing job [\#1645](https://github.com/bensheldon/good_job/pull/1645) ([lsylvester](https://github.com/lsylvester))
+- Allow `GoodJob.preserve_job_records` to take a lambda that is callable after each job executes [\#1640](https://github.com/bensheldon/good_job/pull/1640) ([bensheldon](https://github.com/bensheldon))
+
+**Merged pull requests:**
+
+- Fix JRuby in development lockfile, with test [\#1734](https://github.com/bensheldon/good_job/pull/1734) ([bensheldon](https://github.com/bensheldon))
+- Add herb to linter [\#1732](https://github.com/bensheldon/good_job/pull/1732) ([bensheldon](https://github.com/bensheldon))
+- Update development dependencies; apply Rubocop to\_h lints [\#1728](https://github.com/bensheldon/good_job/pull/1728) ([bensheldon](https://github.com/bensheldon))
+
 ## [v4.14.2](https://github.com/bensheldon/good_job/tree/v4.14.2) (2026-04-06)
 
 [Full Changelog](https://github.com/bensheldon/good_job/compare/v4.14.1...v4.14.2)

data/README.md

@@ -303,13 +303,13 @@ Available configuration options are:
 - `cron_graceful_restart_period` (integer) when restarting cron, attempt to re-enqueue jobs that would have been enqueued by cron within this time period (e.g. `1.minute`). This should match the expected downtime during deploys.
 - `enable_listen_notify` (boolean) whether to enqueue and read jobs with Postgres LISTEN/NOTIFY. Defaults to `true`. You can also set this with the environment variable `GOOD_JOB_ENABLE_LISTEN_NOTIFY`.
 - `cron` (hash) cron configuration. Defaults to `{}`. You can also set this as a JSON string with the environment variable `GOOD_JOB_CRON`
-- `cleanup_discarded_jobs` (boolean) whether to destroy discarded jobs when cleaning up preserved jobs using the `$ good_job cleanup_preserved_jobs` CLI command or calling `GoodJob.cleanup_preserved_jobs`. Defaults to `true`. Can also be set with  the environment variable `GOOD_JOB_CLEANUP_DISCARDED_JOBS`. _This configuration is only used when {GoodJob.preserve_job_records} is `true`._
-- `cleanup_preserved_jobs_before_seconds_ago` (integer) number of seconds to preserve jobs when using the `$ good_job cleanup_preserved_jobs` CLI command or calling `GoodJob.cleanup_preserved_jobs`. Defaults to `1209600` (14 days). Can also be set with  the environment variable `GOOD_JOB_CLEANUP_PRESERVED_JOBS_BEFORE_SECONDS_AGO`.  _This configuration is only used when {GoodJob.preserve_job_records} is `true`._
+- `cleanup_discarded_jobs` (boolean) whether to destroy discarded jobs when cleaning up preserved jobs using the `$ good_job cleanup_preserved_jobs` CLI command or calling `GoodJob.cleanup_preserved_jobs`. Defaults to `true`. Can also be set with the environment variable `GOOD_JOB_CLEANUP_DISCARDED_JOBS`.
+- `cleanup_preserved_jobs_before_seconds_ago` (integer) number of seconds to preserve jobs when using the `$ good_job cleanup_preserved_jobs` CLI command or calling `GoodJob.cleanup_preserved_jobs`. Defaults to `1209600` (14 days). Can also be set with  the environment variable `GOOD_JOB_CLEANUP_PRESERVED_JOBS_BEFORE_SECONDS_AGO`.
 - `cleanup_interval_jobs` (integer) Number of jobs a Scheduler will execute before cleaning up preserved jobs. Defaults to `1000`. Disable with `false`. Can also be set with  the environment variable `GOOD_JOB_CLEANUP_INTERVAL_JOBS` and disabled with `0`).
 - `cleanup_interval_seconds` (integer) Number of seconds a Scheduler will wait before cleaning up preserved jobs. Defaults to `600` (10 minutes). Disable with `false`. Can also be set with  the environment variable `GOOD_JOB_CLEANUP_INTERVAL_SECONDS` and disabled with `0`).
 - `inline_execution_respects_schedule` (boolean) Opt-in to future behavior of inline execution respecting scheduled jobs. Defaults to `false`.
 - `logger` ([Rails Logger](https://api.rubyonrails.org/classes/ActiveSupport/Logger.html)) lets you set a custom logger for GoodJob. It should be an instance of a Rails `Logger` (Default: `Rails.logger`).
-- `preserve_job_records` (boolean) keeps job records in your database even after jobs are completed. (Default: `true`)
+- `preserve_job_records` (boolean, symbol, or lambda) keeps job records in your database even after jobs are completed. If set to `true`, all job records are preserved. If set to `:on_unhandled_error`, only jobs that finished with an unhandled error are preserved. If set to a lambda, the lambda will be called with the error_event (e.g., `:discarded`, `:retry_stopped`, or `:unhandled`) and should return a boolean indicating whether to preserve the job. (Default: `true`)
 - `advisory_lock_heartbeat` (boolean) whether to use an advisory lock for the purpose of determining whether an execeution process is active. (Default `true` in Development; `false` in other environments)
 - `retry_on_unhandled_error` (boolean) causes jobs to be re-queued and retried if they raise an instance of `StandardError`. Be advised this may lead to jobs being repeated infinitely ([see below for more on retries](#retries)). Instances of `Exception`, like SIGINT, will *always* be retried, regardless of this attribute’s value. (Default: `false`)
 - `on_thread_error` (proc, lambda, or callable) will be called when there is an Exception. It can be useful for logging errors to bug tracking services, like Sentry or Airbrake. Example:
@@ -375,7 +375,7 @@ GoodJob.active_record_parent_class = "ApplicationRecord"
 The following options are also configurable via accessors, but you are encouraged to use the configuration attributes instead because these may be deprecated and removed in the future:
 
 - **`GoodJob.logger`** ([Rails Logger](https://api.rubyonrails.org/classes/ActiveSupport/Logger.html)) lets you set a custom logger for GoodJob. It should be an instance of a Rails `Logger`.
-- **`GoodJob.preserve_job_records`** (boolean) keeps job records in your database even after jobs are completed. (Default: `true`)
+- **`GoodJob.preserve_job_records`** (boolean, symbol, or lambda) keeps job records in your database even after jobs are completed. If set to `true`, all job records are preserved. If set to `:on_unhandled_error`, only jobs that finished with an unhandled error are preserved. If set to a lambda, the lambda will be called with Active Job instance, and if it exists, the exception the error_event (e.g., `:discarded`, `:retry_stopped`, or `:unhandled`) and should return a boolean indicating whether to preserve the job (e.g. `-> (active_job, error, error_event) { !(active_job.is_a(Turbo::Streams::BroadcastStreamJob) || error_event == :retry_stopped`). (Default: `true`)
 - **`GoodJob.retry_on_unhandled_error`** (boolean) causes jobs to be re-queued and retried if they raise an instance of `StandardError`. Be advised this may lead to jobs being repeated infinitely ([see below for more on retries](#retries)). Instances of `Exception`, like SIGINT, will *always* be retried, regardless of this attribute’s value. (Default: `false`)
 - **`GoodJob.on_thread_error`** (proc, lambda, or callable) will be called when there is an Exception. It can be useful for logging errors to bug tracking services, like Sentry or Airbrake.
 
@@ -538,6 +538,78 @@ Labels can be used to search jobs in the Dashboard. For example, to find all job
 
 GoodJob can extend Active Job to provide limits on concurrently running jobs, either at time of _enqueue_ or at _perform_. Limiting concurrency can help prevent duplicate, double or unnecessary jobs from being enqueued, or race conditions when performing, for example when interacting with 3rd-party APIs.
 
+```ruby
+class MyJob < ApplicationJob
+  include GoodJob::ActiveJobExtensions::Concurrency
+
+  # Define one or more concurrency rules. Each rule is scoped to a label,
+  # which is a value derived from the job's arguments at enqueue time and
+  # stored on the job record. Jobs must be enqueued with the matching label
+  # via `good_job_labels:` for the rule to apply.
+  #
+  # Multiple rules can be defined; they are evaluated in order and the first
+  # exceeded rule short-circuits the rest.
+  good_job_concurrency_rule(
+    # A label that scopes this rule. Can be a static String or a Lambda/Proc
+    # invoked in the context of the job instance. The rule only applies to jobs
+    # that were enqueued with this label in `good_job_labels`.
+    label: -> { arguments.first[:user_id] },
+
+    # Maximum number of unfinished jobs with this label to allow.
+    # Can be an Integer or Lambda/Proc invoked in the context of the job.
+    total_limit: 1,
+
+    # Or, if more control is needed:
+    # Maximum number of jobs with this label to be concurrently enqueued
+    # (excludes performing jobs). Can be an Integer or Lambda/Proc.
+    enqueue_limit: 2,
+
+    # Maximum number of jobs with this label to be concurrently performed
+    # (excludes enqueued jobs). Can be an Integer or Lambda/Proc.
+    perform_limit: 1,
+
+    # Maximum number of jobs with this label to be enqueued within the time
+    # period, looking backwards from now. Must be [count, period].
+    enqueue_throttle: [10, 1.minute],
+
+    # Maximum number of jobs with this label to be performed within the time
+    # period, looking backwards from now. Must be [count, period].
+    perform_throttle: [100, 1.hour],
+
+    # Note: Under heavy load, the total number of jobs may exceed the
+    # sum of `enqueue_limit` and `perform_limit` because of race conditions
+    # caused by imperfectly disjunctive states. If you need to constrain
+    # the total number of jobs, use `total_limit` instead. See #378.
+  )
+  # Additional rules
+  good_job_concurrency_rule(...)
+  good_job_concurrency_rule(...)
+
+  def perform(user_id:)
+    # do work
+  end
+end
+```
+
+Jobs must be enqueued with the matching label for rules to take effect:
+
+```ruby
+MyJob.set(good_job_labels: [current_user.id]).perform_later(user_id: current_user.id)
+```
+
+#### How concurrency controls work
+
+GoodJob's concurrency control strategy for `perform_limit` is "optimistic retry with an incremental backoff".  The [code is readable](https://github.com/bensheldon/good_job/blob/main/lib/good_job/active_job_extensions/concurrency.rb).
+
+- "Optimistic" meaning that the implementation's performance trade-off assumes that collisions are atypical (e.g. two users enqueue the same job at the same time) rather than regular (e.g. the system enqueues thousands of colliding jobs at the same time). Depending on your concurrency requirements, you may also want to manage concurrency through the number of GoodJob threads and processes that are performing a given queue.
+- "Retry with an incremental backoff" means that when `perform_limit` is exceeded, the job will raise a `GoodJob::ActiveJobExtensions::Concurrency::ConcurrencyExceededError` which is caught by a `retry_on` handler which re-schedules the job to execute in the near future with an incremental backoff.
+- First-in-first-out job execution order is not preserved when a job is retried with incremental back-off.
+- For pessimistic usecases that collisions are expected, use number of threads/processes (e.g., `good_job --queues "serial:1;-serial:5"`) to control concurrency. It is also a good idea to use `perform_limit` as backstop.
+
+#### Legacy: `good_job_control_concurrency_with`
+
+The original concurrency interface uses a single configuration hash and scopes limits to a concurrency _key_ (a string derived from the job) stored on the job record, rather than a label. It remains fully supported.
+
 ```ruby
 class MyJob < ApplicationJob
   include GoodJob::ActiveJobExtensions::Concurrency
@@ -568,11 +640,6 @@ class MyJob < ApplicationJob
     # with two elements: the number of jobs and the time period.
     perform_throttle: [100, 1.hour],
 
-    # Note: Under heavy load, the total number of jobs may exceed the
-    # sum of `enqueue_limit` and `perform_limit` because of race conditions
-    # caused by imperfectly disjunctive states. If you need to constrain
-    # the total number of jobs, use `total_limit` instead. See #378.
-
     # A unique key to be globally locked against.
     # Can be String or Lambda/Proc that is invoked in the context of the job.
     #
@@ -606,15 +673,6 @@ job = MyJob.perform_later("Alice", version: 'v1')
 job.good_job_concurrency_key #=> "MyJob-default-Alice-v1"
 ```
 
-#### How concurrency controls work
-
-GoodJob's concurrency control strategy for `perform_limit` is "optimistic retry with an incremental backoff".  The [code is readable](https://github.com/bensheldon/good_job/blob/main/lib/good_job/active_job_extensions/concurrency.rb).
-
-- "Optimistic" meaning that the implementation's performance trade-off assumes that collisions are atypical (e.g. two users enqueue the same job at the same time) rather than regular (e.g. the system enqueues thousands of colliding jobs at the same time). Depending on your concurrency requirements, you may also want to manage concurrency through the number of GoodJob threads and processes that are performing a given queue.
-- "Retry with an incremental backoff" means that when `perform_limit` is exceeded, the job will raise a `GoodJob::ActiveJobExtensions::Concurrency::ConcurrencyExceededError` which is caught by a `retry_on` handler which re-schedules the job to execute in the near future with an incremental backoff.
-- First-in-first-out job execution order is not preserved when a job is retried with incremental back-off.
-- For pessimistic usecases that collisions are expected, use number of threads/processes (e.g., `good_job --queues "serial:1;-serial:5"`) to control concurrency. It is also a good idea to use `perform_limit` as backstop.
-
 ### Cron-style repeating/recurring jobs
 
 GoodJob can enqueue Active Job jobs on a recurring basis that can be used as a replacement for cron.
@@ -1390,7 +1448,11 @@ To instead delete job records immediately after they are finished:
 
 ```ruby
 # config/initializers/good_job.rb
-config.good_job.preserve_job_records = false # defaults to true; can also be `false` or `:on_unhandled_error`
+config.good_job.preserve_job_records = false # defaults to true; can also be `false`, `:on_unhandled_error`, or a lambda that takes error_event argument
+
+# Example of using a lambda to preserve only discarded jobs
+config.good_job.preserve_job_records = ->(error_event) { error_event == :discarded }
+
 ```
 
 GoodJob will automatically delete preserved job records after 14 days. The retention period, as well as the frequency GoodJob checks for deletable records can be configured:
@@ -1433,6 +1495,53 @@ travel_to(15.minutes.from_now) { GoodJob.perform_inline }
 
 _Note: Rails `travel`/`travel_to` time helpers do not have millisecond precision, so you must leave at least 1 second between the schedule and time traveling for the job to be executed. This [behavior may change in Rails 7.1](https://github.com/rails/rails/pull/44088)._
 
+### SKIP LOCKED experimental mode
+
+By default, GoodJob claims jobs using PostgreSQL advisory locks. As an alternative, GoodJob can use `SELECT FOR UPDATE SKIP LOCKED` to claim jobs, which writes the lock state directly to the `good_jobs` table rather than relying on session-level advisory locks.
+
+Two strategies are available:
+
+- **`:skiplocked`** — Claims jobs using `SELECT FOR UPDATE SKIP LOCKED` only. No advisory locks are held. Compatible with PgBouncer in transaction mode.
+- **`:hybrid`** — Claims jobs using `SELECT FOR UPDATE SKIP LOCKED` and _also_ acquires a session-level advisory lock on the job. Intended for rolling deploys where some workers are still using the default `:advisory` strategy.
+
+Configure the lock strategy in an initializer or via environment variable:
+
+```ruby
+# config/initializers/good_job.rb
+GoodJob.configure do |config|
+  config.lock_strategy = :skiplocked
+end
+```
+
+```bash
+GOOD_JOB_LOCK_STRATEGY=skiplocked
+```
+
+All three strategies (`:advisory`, `:skiplocked`, `:hybrid`) can coexist safely during a rolling deploy — each strategy excludes jobs that are already locked by another worker regardless of which strategy that worker uses.
+
+#### PgBouncer configuration
+
+GoodJob's `:skiplocked` mode makes it compatible with PgBouncer in _transaction_ mode. In addition to setting the lock strategy, you must also disable the `LISTEN/NOTIFY` notifier (which requires a persistent connection) and rely on polling instead:
+
+```ruby
+# config/initializers/good_job.rb
+GoodJob.configure do |config|
+  config.lock_strategy = :skiplocked
+  config.enable_listen_notify = false
+  config.advisory_lock_heartbeat = false
+  config.poll_interval = 5 # seconds; tune based on your latency tolerance
+end
+```
+
+```bash
+GOOD_JOB_LOCK_STRATEGY=skiplocked
+GOOD_JOB_ENABLE_LISTEN_NOTIFY=false
+GOOD_JOB_ADVISORY_LOCK_HEARTBEAT=false
+GOOD_JOB_POLL_INTERVAL=5
+```
+
+With these four settings, GoodJob will not hold any session-level state between queries and is safe to use behind PgBouncer in transaction mode.
+
 ### PgBouncer compatibility
 
 GoodJob is not compatible with PgBouncer in _transaction_ mode, but is compatible with PgBouncer's _connection_ mode. GoodJob uses connection-based advisory locks and LISTEN/NOTIFY, both of which require full database connections.

data/app/controllers/good_job/cleaner_controller.rb

@@ -7,7 +7,7 @@ module GoodJob
 
       @discarded_jobs_grouped_by_exception =
         GoodJob::Job.discarded
-                    .select(<<-SQL.squish)
+                    .select(<<~SQL.squish)
                       SPLIT_PART(error, ': ', 1) AS exception_class,
                       count(id) AS failed,
                       COUNT(id) FILTER (WHERE "finished_at" > NOW() - INTERVAL '1 HOUR') AS last_1_hour,
@@ -21,7 +21,7 @@ module GoodJob
 
       @discarded_jobs_grouped_by_class =
         GoodJob::Job.discarded
-                    .select(<<-SQL.squish)
+                    .select(<<~SQL.squish)
                       job_class,
                       count(id) AS failed,
                       COUNT(*) FILTER (WHERE "finished_at" > NOW() - INTERVAL '1 HOUR') AS last_1_hour,

data/app/filters/good_job/base_filter.rb

@@ -52,6 +52,7 @@ module GoodJob
     def to_params(override = {})
       {
         job_class: params[:job_class],
+        label: params[:label],
         limit: params[:limit],
         queue_name: params[:queue_name],
         query: params[:query],

data/app/filters/good_job/jobs_filter.rb

@@ -23,41 +23,14 @@ module GoodJob
     end
 
     def filtered_query(filter_params = params)
-      query = base_query
-
-      query = query.job_class(filter_params[:job_class]) if filter_params[:job_class].present?
-      query = query.where(queue_name: filter_params[:queue_name]) if filter_params[:queue_name].present?
-
-      search_query = filter_params[:query]&.strip
-      if search_query.present?
-        query = if query_is_uuid_and_job_exists?(search_query)
-                  query.where(active_job_id: search_query)
-                else
-                  query.search_text(search_query)
-                end
-      end
-
-      query = query.where(cron_key: filter_params[:cron_key]) if filter_params[:cron_key].present?
-      query = query.where(finished_at: finished_since(filter_params[:finished_since])..) if filter_params[:finished_since].present?
-
-      if filter_params[:state]
-        case filter_params[:state]
-        when 'discarded'
-          query = query.discarded
-        when 'succeeded'
-          query = query.succeeded
-        when 'retried'
-          query = query.retried
-        when 'scheduled'
-          query = query.scheduled
-        when 'running'
-          query = query.running
-        when 'queued'
-          query = query.queued
-        end
-      end
-
-      query
+      base_query
+        .merge(filter_by_job_class(filter_params[:job_class]))
+        .merge(filter_by_queue_name(filter_params[:queue_name]))
+        .merge(filter_by_label(filter_params[:label]))
+        .merge(filter_by_search_query(filter_params[:query]))
+        .merge(filter_by_cron_key(filter_params[:cron_key]))
+        .merge(filter_by_finished_since(filter_params[:finished_since]))
+        .merge(filter_by_state(filter_params[:state]))
     end
 
     def filtered_count
@@ -79,6 +52,59 @@ module GoodJob
 
     private
 
+    def filter_by_job_class(job_class)
+      return {} if job_class.blank?
+
+      GoodJob::Job.job_class(job_class)
+    end
+
+    def filter_by_queue_name(queue_name)
+      return {} if queue_name.blank?
+
+      GoodJob::Job.where(queue_name: queue_name)
+    end
+
+    def filter_by_label(label)
+      return {} if label.blank?
+
+      GoodJob::Job.labeled(label)
+    end
+
+    def filter_by_search_query(query)
+      search_query = query&.strip
+      return {} if search_query.blank?
+
+      if query_is_uuid_and_job_exists?(search_query)
+        GoodJob::Job.where(active_job_id: search_query)
+      else
+        GoodJob::Job.search_text(search_query)
+      end
+    end
+
+    def filter_by_cron_key(cron_key)
+      return {} if cron_key.blank?
+
+      GoodJob::Job.where(cron_key: cron_key)
+    end
+
+    def filter_by_finished_since(since)
+      return {} if since.blank?
+
+      GoodJob::Job.where(finished_at: finished_since(since)..)
+    end
+
+    def filter_by_state(state)
+      case state
+      when 'discarded' then GoodJob::Job.discarded
+      when 'succeeded' then GoodJob::Job.succeeded
+      when 'retried'   then GoodJob::Job.retried
+      when 'scheduled' then GoodJob::Job.scheduled
+      when 'running'   then GoodJob::Job.running
+      when 'queued'    then GoodJob::Job.queued
+      else {}
+      end
+    end
+
     def query_for_records
       filtered_query
     end