good_job 4.13.3 → 4.18.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 2993eeb7c69f566b281456e5d7122dbbc685de9efc5ce56ae7b62edbec5e9d1a
-  data.tar.gz: 9528654eca760b6bcb2bf18890263c4213c0e4df71174e9ab5a55ac55982182b
+  metadata.gz: 9d2eb2f4b216901a3f6abb9197facd9d9738c13fa4b61fcca2ec3ef4f2b64a6a
+  data.tar.gz: 7324f38c349116f108cbf216bffdc1207c2f0fd06ff136b7c0f0a8e0059d16a3
 SHA512:
-  metadata.gz: 1d293a78adc12d75fde3473c84a65c7a4c7cabc6d9e35bb39d9e9c9547d376fd1ff41877b92ceba3a1e87d906a1242d224ed4f61cf9e790146ab56b01111c183
-  data.tar.gz: 1ded68b5610c971520b7f515566d4def597cfca9dfb85e4d099422b756f40720ccba94864a2998bf7b7f86bb7d6588b59e86e5ec93e62672b899b12d2cbcba7b
+  metadata.gz: 62c30d3afcfa5c7f697f5b156cdced9cf45757f2e05e5e53657fbdf11c1fb0bab0e0e63dad516206737e697bb39d3985c4d0b2fcfb0933c6225fc724a6aca4c7
+  data.tar.gz: 0d5174c12282329ec248573bfd28a0a86538f7b65b94bf9918c7434bce691a43711017e595b47afb3e200125df5fc33c63b307a545c3d1c7ffd2eb11405741af

data/CHANGELOG.md

@@ -1,5 +1,180 @@
 # Changelog
 
+## [v4.18.2](https://github.com/bensheldon/good_job/tree/v4.18.2) (2026-04-20)
+
+[Full Changelog](https://github.com/bensheldon/good_job/compare/v4.18.1...v4.18.2)
+
+**Implemented enhancements:**
+
+- Add dashboard indexes for queue\_name, created\_at, and discarded jobs [\#1754](https://github.com/bensheldon/good_job/pull/1754) ([AliOsm](https://github.com/AliOsm))
+
+**Fixed bugs:**
+
+- ArgumentError: GoodJob::Job\(...\) is not an ActiveRecord::Relation [\#1759](https://github.com/bensheldon/good_job/issues/1759)
+- Fix ArgumentError when using perform\_throttle without a label [\#1760](https://github.com/bensheldon/good_job/pull/1760) ([bensheldon](https://github.com/bensheldon))
+
+**Merged pull requests:**
+
+- Speed up succeeded count via complement subtraction [\#1758](https://github.com/bensheldon/good_job/pull/1758) ([AliOsm](https://github.com/AliOsm))
+- Speed up ScheduledByQueueChart with inner-query pushdown and \(scheduled\_at, queue\_name\) index [\#1757](https://github.com/bensheldon/good_job/pull/1757) ([AliOsm](https://github.com/AliOsm))
+
+## [v4.18.1](https://github.com/bensheldon/good_job/tree/v4.18.1) (2026-04-18)
+
+[Full Changelog](https://github.com/bensheldon/good_job/compare/v4.18.0...v4.18.1)
+
+**Implemented enhancements:**
+
+- Add an ActiveJob extension for throttling [\#315](https://github.com/bensheldon/good_job/issues/315)
+
+**Fixed bugs:**
+
+- Make job lifecycle methods lock-strategy-aware [\#1756](https://github.com/bensheldon/good_job/pull/1756) ([bensheldon](https://github.com/bensheldon))
+- Fix concurrent PG connection access in ProcessHeartbeat\#refresh\_process [\#1755](https://github.com/bensheldon/good_job/pull/1755) ([bensheldon](https://github.com/bensheldon))
+
+**Closed issues:**
+
+- Job stuck in queued state and never picked up [\#1590](https://github.com/bensheldon/good_job/issues/1590)
+- Refactor the Notifier to be more of a generic Reactor [\#811](https://github.com/bensheldon/good_job/issues/811)
+
+## [v4.18.0](https://github.com/bensheldon/good_job/tree/v4.18.0) (2026-04-17)
+
+[Full Changelog](https://github.com/bensheldon/good_job/compare/v4.17.0...v4.18.0)
+
+**Implemented enhancements:**
+
+- Make bulk action buttons responsive to job state filter [\#1751](https://github.com/bensheldon/good_job/pull/1751) ([bensheldon](https://github.com/bensheldon))
+- Introduce GoodJob::InterruptedError string for interrupted execution records [\#1750](https://github.com/bensheldon/good_job/pull/1750) ([bensheldon](https://github.com/bensheldon))
+- Add GoodJob.handled\_exceptions config; include NotImplementedError by default [\#1748](https://github.com/bensheldon/good_job/pull/1748) ([bensheldon](https://github.com/bensheldon))
+- Allow adding the currently executing job to a batch [\#1746](https://github.com/bensheldon/good_job/pull/1746) ([bensheldon](https://github.com/bensheldon))
+- Show split enabled/paused badge for cron schedules in navbar [\#1744](https://github.com/bensheldon/good_job/pull/1744) ([bensheldon](https://github.com/bensheldon))
+
+**Fixed bugs:**
+
+- Replace AR attributes API with explicit accessors; add breaking migration guardrails [\#1753](https://github.com/bensheldon/good_job/pull/1753) ([bensheldon](https://github.com/bensheldon))
+- Fix dashboard pagination omitting jobs created in the same second [\#1749](https://github.com/bensheldon/good_job/pull/1749) ([bensheldon](https://github.com/bensheldon))
+
+**Closed issues:**
+
+- 4.15.0 crashes Tapioca with direct database access while requiring gems [\#1752](https://github.com/bensheldon/good_job/issues/1752)
+- Dashboard omits jobs on the next page when they were created the same second as the preceding job [\#1725](https://github.com/bensheldon/good_job/issues/1725)
+- `ActiveRecord::DuplicateMigrationVersionError` [\#1708](https://github.com/bensheldon/good_job/issues/1708)
+- Adding to Process\_state in Dashboard [\#1702](https://github.com/bensheldon/good_job/issues/1702)
+- jobs\#index perf Issue: ORDER BY uses wrong column for existing index [\#1675](https://github.com/bensheldon/good_job/issues/1675)
+- `NotImplementedError` is always retried [\#1670](https://github.com/bensheldon/good_job/issues/1670)
+- Job retry action doesn't work [\#1624](https://github.com/bensheldon/good_job/issues/1624)
+- Adapt `AdvisoryLockable` to use more secure algorithm instead of MD5 [\#1623](https://github.com/bensheldon/good_job/issues/1623)
+- Labels based on arguments [\#1622](https://github.com/bensheldon/good_job/issues/1622)
+- How to start batches from cron jobs? \(create a batch within a job and add the current job to the batch\) [\#1611](https://github.com/bensheldon/good_job/issues/1611)
+- What's the best way to auto truncate good\_job\_executions table [\#1607](https://github.com/bensheldon/good_job/issues/1607)
+- Is the description of GOOD\_JOB\_EXECUTION\_MODE in the readme correct? [\#1584](https://github.com/bensheldon/good_job/issues/1584)
+- Cron dashboard does not distinguish enabled/disabled jobs [\#1552](https://github.com/bensheldon/good_job/issues/1552)
+- The Cron count in the Dashboard should show enabled and disabled counts [\#1313](https://github.com/bensheldon/good_job/issues/1313)
+- Recording accurate job durations [\#1053](https://github.com/bensheldon/good_job/issues/1053)
+- Jobs won't start until ActiveRecord loaded - gotcha in development environment [\#930](https://github.com/bensheldon/good_job/issues/930)
+- Feature Request: Setting specific default locale for good job [\#921](https://github.com/bensheldon/good_job/issues/921)
+- Avoid querying through `serialized_params` [\#876](https://github.com/bensheldon/good_job/issues/876)
+- Allow separate \*\_keys for execution/enqueue/rate limits [\#753](https://github.com/bensheldon/good_job/issues/753)
+
+**Merged pull requests:**
+
+- Document initializer workaround for deferred autoloading in development [\#1747](https://github.com/bensheldon/good_job/pull/1747) ([bensheldon](https://github.com/bensheldon))
+
+## [v4.17.0](https://github.com/bensheldon/good_job/tree/v4.17.0) (2026-04-17)
+
+[Full Changelog](https://github.com/bensheldon/good_job/compare/v4.16.0...v4.17.0)
+
+**Implemented enhancements:**
+
+- Introduce advisory lock key customization support methods [\#1722](https://github.com/bensheldon/good_job/pull/1722) ([amkisko](https://github.com/amkisko))
+
+**Merged pull requests:**
+
+- Convert UI JavaScript modules to Stimulus controllers [\#1743](https://github.com/bensheldon/good_job/pull/1743) ([bensheldon](https://github.com/bensheldon))
+- Development: Strip pg\_catalog namespace from enable\_extension in schema.rb [\#1742](https://github.com/bensheldon/good_job/pull/1742) ([bensheldon](https://github.com/bensheldon))
+- Use system tmpdir for generator specs to eliminate bin/rails rename workaround [\#1740](https://github.com/bensheldon/good_job/pull/1740) ([bensheldon](https://github.com/bensheldon))
+
+## [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)
+
+**Closed issues:**
+
+- Incompatible with permanent\_connection\_checkout = :disallowed [\#1729](https://github.com/bensheldon/good_job/issues/1729)
+
+**Merged pull requests:**
+
+- Replace Base.connection with lease\_connection and with\_connection throughout [\#1730](https://github.com/bensheldon/good_job/pull/1730) ([bensheldon](https://github.com/bensheldon))
+
+## [v4.14.1](https://github.com/bensheldon/good_job/tree/v4.14.1) (2026-04-03)
+
+[Full Changelog](https://github.com/bensheldon/good_job/compare/v4.14.0...v4.14.1)
+
+**Fixed bugs:**
+
+- Fix N+1 queries on cron entries dashboard index page [\#1727](https://github.com/bensheldon/good_job/pull/1727) ([clinejj](https://github.com/clinejj))
+
+## [v4.14.0](https://github.com/bensheldon/good_job/tree/v4.14.0) (2026-03-31)
+
+[Full Changelog](https://github.com/bensheldon/good_job/compare/v4.13.3...v4.14.0)
+
+**Implemented enhancements:**
+
+- Consider using pg\_cron for Cron-style repeating/recurring jobs [\#328](https://github.com/bensheldon/good_job/issues/328)
+- Add Batch.enqueue\_all for bulk-enqueuing multiple batches [\#1726](https://github.com/bensheldon/good_job/pull/1726) ([AliOsm](https://github.com/AliOsm))
+- Allow perform\_all\_later to enqueue to Batches [\#1720](https://github.com/bensheldon/good_job/pull/1720) ([bensheldon](https://github.com/bensheldon))
+
+**Closed issues:**
+
+- perform\_all\_later not intercepted by Batch [\#1719](https://github.com/bensheldon/good_job/issues/1719)
+- Deprecate and drop :on\_unhandled\_error option [\#1706](https://github.com/bensheldon/good_job/issues/1706)
+
+**Merged pull requests:**
+
+- Bump actions/upload-artifact from 6 to 7 [\#1718](https://github.com/bensheldon/good_job/pull/1718) ([dependabot[bot]](https://github.com/apps/dependabot))
+
 ## [v4.13.3](https://github.com/bensheldon/good_job/tree/v4.13.3) (2026-02-18)
 
 [Full Changelog](https://github.com/bensheldon/good_job/compare/v4.13.2...v4.13.3)

data/README.md

@@ -134,7 +134,15 @@ For more of the story of GoodJob, read the [introductory blog post](https://isla
     ```
 
 1. **In Rails' development environment**, by default, GoodJob's Adapter executes jobs `async` in a background thread pool in `rails server`.
-    - Because of Rails deferred autoloading, jobs enqueued via the `rails console` may not begin executing on a separate server process until the Rails application is fully initialized by loading a web page once.
+    - Because of Rails deferred autoloading, jobs enqueued via the `rails console` may not begin executing on a separate server process until the Rails application is fully initialized by loading a web page once. To force early initialization (so pre-existing jobs run immediately on boot), add the following to an initializer:
+
+        ```ruby
+        # config/initializers/good_job.rb
+        Rails.configuration.after_initialize do
+          ActiveJob::Base && ActiveRecord::Base
+        end
+        ```
+
     - Remember, only Active Job's `perform_later` sends jobs to the queue adapter; Active Job's `perform_now` executes the job immediately and does not invoke the queue adapter. GoodJob is not involved in `perform_now` jobs.
 1. **In Rails' test environment**, by default, GoodJob's Adapter executes jobs `inline` immediately in the current thread.
     - Future-scheduled jobs can be executed with `GoodJob.perform_inline` using a tool like Timecop or `ActiveSupport::Testing::TimeHelpers`.
@@ -303,13 +311,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 +383,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 +546,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 +648,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 +681,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.
@@ -1041,7 +1107,7 @@ end
 
 Note that when running jobs in `:inline` execution mode, `GoodJob.current_thread_running?` will always be truthy and `GoodJob.current_thread_shutting_down?` will always be falsey.
 
-Jobs will be automatically retried if the process is interrupted while performing a job and the job is unable to finish before the timeout or as the result of a `SIGKILL` or power failure.
+Jobs will be automatically retried if the process is interrupted while performing a job and the job is unable to finish before the timeout or as the result of a `SIGKILL` or power failure. The interrupted execution's error record will show `GoodJob::InterruptedError` to distinguish it from the rescuable `GoodJob::InterruptError` that is raised when the job is retried.
 
 If you need more control over interrupt-caused retries, include the `GoodJob::ActiveJobExtensions::InterruptErrors` extension in your job class. When an interrupted job is retried, the extension will raise a `GoodJob::InterruptError` exception within the job, which allows you to use Active Job's `retry_on` and `discard_on` to control the behavior of the job.
 
@@ -1261,6 +1327,21 @@ To explain where this value is used, here is the pseudo-query that GoodJob uses
   )
 ```
 
+By default, advisory lock keys are derived with `md5`. The string key (e.g. `good_jobs-<active_job_id>`) is hashed and truncated to a 64-bit bigint, which is the key space PostgreSQL advisory locks operate in. `md5` is used for its wide availability — no PostgreSQL extensions required — and good bit distribution, not for any cryptographic property.
+
+If you need a different hash strategy, set it globally:
+
+```ruby
+GoodJob::AdvisoryLockable.hash_function = "sha256"
+```
+
+Supported values are `md5`, `sha1`, `sha224`, `sha256`, `sha384`, `sha512`, `hashtext`, and `uuid_v5`.
+
+- `md5` (default): requires no PostgreSQL extensions.
+- `hashtext`: PostgreSQL's internal 32-bit hash; requires no extensions.
+- `sha*` algorithms require the `pgcrypto` extension (`digest()`).
+- `uuid_v5` requires the `uuid-ossp` extension (`uuid_generate_v5()`).
+
 ### Execute jobs async / in-process
 
 GoodJob can execute jobs "async" in the same process as the web server (e.g. `bin/rails s`). GoodJob's async execution mode offers benefits of economy by not requiring a separate job worker process, but with the tradeoff of increased complexity. Async mode can be configured in two ways:
@@ -1390,7 +1471,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 +1518,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/charts/good_job/performance_index_chart.rb

@@ -23,7 +23,7 @@ module GoodJob
         ORDER BY timestamp ASC
       SQL
 
-      executions_data = GoodJob::Job.connection.exec_query(GoodJob::Job.pg_or_jdbc_query(sum_query), "GoodJob Performance Chart", start_end_binds)
+      executions_data = GoodJob::Job.connection_pool.with_connection { |conn| conn.exec_query(GoodJob::Job.pg_or_jdbc_query(sum_query), "GoodJob Performance Chart", start_end_binds) }
 
       job_names = executions_data.reject { |d| d['sum'].nil? }.map { |d| d['job_class'] || BaseFilter::EMPTY }.uniq
       labels = []

data/app/charts/good_job/performance_show_chart.rb

@@ -40,7 +40,7 @@ module GoodJob
       ]
       labels = BUCKET_INTERVALS.map { |interval| GoodJob::ApplicationController.helpers.format_duration(interval) }
       labels[-1] = I18n.t("good_job.performance.show.slow")
-      executions_data = GoodJob::Job.connection.exec_query(GoodJob::Job.pg_or_jdbc_query(sum_query), "GoodJob Performance Job Chart", binds)
+      executions_data = GoodJob::Job.connection_pool.with_connection { |conn| conn.exec_query(GoodJob::Job.pg_or_jdbc_query(sum_query), "GoodJob Performance Job Chart", binds) }
       executions_data = executions_data.to_a.index_by { |data| data["bucket_index"] }
 
       bucket_data = 0.upto(BUCKET_INTERVALS.count).map do |bucket_index|

data/app/charts/good_job/scheduled_by_queue_chart.rb

@@ -8,6 +8,25 @@ module GoodJob
     end
 
     def data
+      binds = start_end_binds
+      start_time, end_time = binds.map(&:value)
+
+      # Align the inner range predicate to the same hour buckets the outer generate_series
+      # produces. Doing the truncation in SQL (rather than in Ruby with beginning_of_hour)
+      # keeps both sides on the same grid even when the app's time zone has a fractional
+      # offset from UTC (e.g. IST +05:30). AR serializes Time binds as UTC, so the outer
+      # date_trunc operates in UTC, and this predicate must match that.
+      pushdown = <<~SQL.squish
+        "good_jobs"."scheduled_at" >= date_trunc('hour', ?::timestamp)
+        AND "good_jobs"."scheduled_at" < date_trunc('hour', ?::timestamp) + interval '1 hour'
+      SQL
+
+      inner_sql = @filter.filtered_query
+                         .except(:select, :order)
+                         .where(pushdown, start_time, end_time)
+                         .select(:queue_name, :scheduled_at)
+                         .to_sql
+
       count_query = <<~SQL.squish
         SELECT *
         FROM generate_series(
@@ -20,15 +39,13 @@ module GoodJob
               date_trunc('hour', scheduled_at) AS scheduled_at,
               queue_name,
               count(*) AS count
-            FROM (
-              #{@filter.filtered_query.except(:select, :order).select(:queue_name, :scheduled_at).to_sql}
-            ) sources
+            FROM (#{inner_sql}) sources
             GROUP BY date_trunc('hour', scheduled_at), queue_name
         ) sources ON sources.scheduled_at = timestamp
         ORDER BY timestamp ASC
       SQL
 
-      executions_data = GoodJob::Job.connection.exec_query(GoodJob::Job.pg_or_jdbc_query(count_query), "GoodJob Dashboard Chart", start_end_binds)
+      executions_data = GoodJob::Job.connection_pool.with_connection { |conn| conn.exec_query(GoodJob::Job.pg_or_jdbc_query(count_query), "GoodJob Dashboard Chart", binds) }
 
       queue_names = executions_data.reject { |d| d['count'].nil? }.map { |d| d['queue_name'] || BaseFilter::EMPTY }.uniq
       labels = []

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/controllers/good_job/cron_entries_controller.rb

@@ -4,6 +4,10 @@ module GoodJob
   class CronEntriesController < GoodJob::ApplicationController
     def index
       @cron_entries = CronEntry.all
+      @last_jobs = CronEntry.last_jobs_by_key(@cron_entries)
+      @enabled_states = GoodJob::Setting.cron_keys_enabled(
+        @cron_entries.map { |entry| [entry.key, entry.enabled_by_default?] }
+      )
     end
 
     def show

data/app/controllers/good_job/metrics_controller.rb

@@ -5,7 +5,10 @@ module GoodJob
     def primary_nav
       jobs_count = GoodJob::Job.count
       batches_count = GoodJob::BatchRecord.all.size
-      cron_entries_count = GoodJob::CronEntry.all.size
+      cron_entries = GoodJob::CronEntry.all
+      cron_entries_count = cron_entries.size
+      cron_entries_enabled_count = cron_entries.count(&:enabled?)
+      cron_entries_paused_count = cron_entries_count - cron_entries_enabled_count
       pauses_count = GoodJob::Setting.paused.values.sum(&:count)
       processes_count = GoodJob::Process.active.count
       discarded_count = GoodJob::Job.discarded.count
@@ -14,6 +17,8 @@ module GoodJob
         jobs_count: helpers.number_to_human(jobs_count),
         batches_count: helpers.number_to_human(batches_count),
         cron_entries_count: helpers.number_to_human(cron_entries_count),
+        cron_entries_enabled_count: helpers.number_to_human(cron_entries_enabled_count),
+        cron_entries_paused_count: helpers.number_to_human(cron_entries_paused_count),
         pauses_count: helpers.number_to_human(pauses_count),
         processes_count: helpers.number_to_human(processes_count),
         discarded_count: helpers.number_to_human(discarded_count),

data/app/filters/good_job/base_filter.rb

@@ -13,8 +13,8 @@ module GoodJob
     end
 
     def records
+      after_id = params[:after_id]
       after_at = params[:after_at].present? ? Time.zone.parse(params[:after_at]) : nil
-      after_id = params[:after_id] if after_at
       limit = params.fetch(:limit, DEFAULT_LIMIT)
 
       query_for_records.display_all(
@@ -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],
@@ -75,10 +76,11 @@ module GoodJob
 
     def next_page_params
       order_column = ordered_by.first
+      last_record = records.last
 
       {
-        after_at: records.last&.send(order_column),
-        after_id: records.last&.id,
+        after_at: last_record&.send(order_column)&.iso8601(6),
+        after_id: last_record&.id,
       }.merge(to_params)
     end