good_job 3.4.3 → 3.4.4

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 8838f9cf09b7dda04c3dc119db41deef4facc8b31a07e879e082898d77915d8d
-  data.tar.gz: a7e146e678ea6432f291f593edfce11497b70201576e299360a026dc83290dda
+  metadata.gz: c54a7908e5803c8f247421375b0ca4a09f97d5b0d21131ef2bfc54e91a4c7eed
+  data.tar.gz: 8a616c9407d2844ee89e2f12fa71c197ddb60e693983c66ce664ac413d0676f0
 SHA512:
-  metadata.gz: 87a1770d3b74c50c6a40bc63ca50ad368578524029b8d11b5221baf721f7c8169051f0c19bc9554962ff61fc9cf51ac397f042ad393a4c19cecb73924db0c6c2
-  data.tar.gz: d707c9b35f41b417628425c74e916c21654992dcb41a27e52fdc88435e74fae09168b85bea81470aeba7eb2236b9d2d57a736ce4c34a5c427c4f82230146d7fa
+  metadata.gz: 0040cd9afa69d73d4c9bf09da90bd7c1e4c73d4dc4251faff13fd495e2c39d081d099163482edb332a392be1dd560ac056705a5261363e8172d2ae7eab20be55
+  data.tar.gz: c4e41bd8da8e2afd309fceb2c0c5eb4b042d85234c4d34f4a687bcb2fe63f9e2f7d0c442c07bf68a248201d5e9c42c2e84dc8022c9f3eace8ea0b97c3995e004

data/CHANGELOG.md

@@ -1,5 +1,18 @@
 # Changelog
 
+## [v3.4.4](https://github.com/bensheldon/good_job/tree/v3.4.4) (2022-08-20)
+
+[Full Changelog](https://github.com/bensheldon/good_job/compare/v3.4.3...v3.4.4)
+
+**Fixed bugs:**
+
+- Keep locale param when submitting dashboard filter [\#707](https://github.com/bensheldon/good_job/pull/707) ([aki77](https://github.com/aki77))
+
+**Merged pull requests:**
+
+- Fix document [\#704](https://github.com/bensheldon/good_job/pull/704) ([aki77](https://github.com/aki77))
+- Describe pessimistic usecases [\#702](https://github.com/bensheldon/good_job/pull/702) ([shouichi](https://github.com/shouichi))
+
 ## [v3.4.3](https://github.com/bensheldon/good_job/tree/v3.4.3) (2022-08-15)
 
 [Full Changelog](https://github.com/bensheldon/good_job/compare/v3.4.2...v3.4.3)
@@ -125,7 +138,6 @@
 
 **Closed issues:**
 
-- Calculating database connections [\#669](https://github.com/bensheldon/good_job/issues/669)
 - Unable to Replace GoodJob's Logger [\#667](https://github.com/bensheldon/good_job/issues/667)
 - Readme should consistently encourage usage of `config.good_job....` instead of `GoodJob.` configuration [\#628](https://github.com/bensheldon/good_job/issues/628)
 - Improve the "Gem development" section of README? [\#551](https://github.com/bensheldon/good_job/issues/551)

data/README.md

@@ -283,7 +283,7 @@ Available configuration options are:
 - `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`)
-- `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: `true`)
+- `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 an Exception. It can be useful for logging errors to bug tracking services, like Sentry or Airbrake. Example:
 
     ```ruby
@@ -452,6 +452,7 @@ GoodJob's concurrency control strategy for `perform_limit` is "optimistic retry
 - "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 --queue "serial:1;-serial:5"`) to control concurrency. It is also a good idea to use `perform_limit` as backstop.
 
 ### Cron-style repeating/recurring jobs
 

data/app/views/good_job/shared/_filter.erb

@@ -5,6 +5,7 @@
     <%= form_with(url: "", method: :get, local: true, id: "filter_form", class: "container-fluid") do |form| %>
       <%= hidden_field_tag :poll, params[:poll] %>
       <%= hidden_field_tag :state, params[:state] %>
+      <%= hidden_field_tag :locale, params[:locale] if params[:locale] %>
       <div class="d-flex flex-row w-100">
         <div class="me-2">
           <select name="queue_name" id="job_queue_filter" class="form-select form-select-sm">

data/lib/good_job/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 module GoodJob
   # GoodJob gem version.
-  VERSION = '3.4.3'
+  VERSION = '3.4.4'
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: good_job
 version: !ruby/object:Gem::Version
-  version: 3.4.3
+  version: 3.4.4
 platform: ruby
 authors:
 - Ben Sheldon
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2022-08-15 00:00:00.000000000 Z
+date: 2022-08-20 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: activejob