solid_queue 1.2.0 → 1.2.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 1d0b2a7e3a5ad6577d52d3528f42ff8862c087f6f406d0f6fd96f12f36db6795
-  data.tar.gz: 4db8708635736bd5ccb32ad619577494c039574fd452a40c3fecc55d0f57c27b
+  metadata.gz: 9066bd5266e43075385bfd3365de2512400960f5cfa7f780dba69e4a3259c07a
+  data.tar.gz: 0a7103f485e445563814874e3113b6ac6dca84c8333bad418c449ebaf3fac1c9
 SHA512:
-  metadata.gz: 2ba5bb04f334bcc56bb0504d0baac497287058c242aaf8fccd85c72e1c72c5107ad38eff211d9c16641a3cc7ad366673a316cf357daf70bdf97009d68b7c5646
-  data.tar.gz: bf7770477e8dd290bd9461bcc5202b5d0832639ed31e7df7e96d192562fe5c0574522f1f689504c6d98c44c14ba389597bd7627fe3ec76c1e76937c0f0eaaac7
+  metadata.gz: 952b71b5cd59ebd79eb51c44f7ed509bf3d4959c010dc0441cff37c0a1bd2ccea97054007bd3a197b287a158342e8791318c841f0d1d9b3dd347986da68bb53a
+  data.tar.gz: 1309ce242499f430667d9677b7ff8807e1b43af33873d9b00575c4c9e13be24824d9520ca24db432901da2616c4ba5a530db83fd29c09c47b820fff3586a75b7

data/README.md

@@ -433,7 +433,9 @@ In the case of recurring tasks, if such error is raised when enqueuing the job c
 
 ## Concurrency controls
 
-Solid Queue extends Active Job with concurrency controls, that allows you to limit how many jobs of a certain type or with certain arguments can run at the same time. When limited in this way, by default, jobs will be blocked from running, and they'll stay blocked until another job finishes and unblocks them, or after the set expiry time (concurrency limit's _duration_) elapses. Alternatively, jobs can be configured to be discarded instead of blocked. This means that if a job with certain arguments has already been enqueued, other jobs with the same characteristics (in the same concurrency _class_) won't be enqueued.
+Solid Queue extends Active Job with concurrency controls, that allows you to limit how many jobs of a certain type or with certain arguments can run at the same time. When limited in this way, **by default, jobs will be blocked from running**, and they'll stay blocked until another job finishes and unblocks them, or after the set expiry time (concurrency limit's _duration_) elapses.
+
+**Alternatively, jobs can be configured to be discarded instead of blocked**. This means that if a job with certain arguments has already been enqueued, other jobs with the same characteristics (in the same concurrency _class_) won't be enqueued.
 
 ```ruby
 class MyJob < ApplicationJob
@@ -496,6 +498,29 @@ Jobs are unblocked in order of priority but **queue order is not taken into acco
 
 Finally, failed jobs that are automatically or manually retried work in the same way as new jobs that get enqueued: they get in the queue for getting an open semaphore, and whenever they get it, they'll be run. It doesn't matter if they had already gotten an open semaphore in the past.
 
+### Scheduled jobs
+
+Jobs set to run in the future (via Active Job's `wait` or `wait_until` options) have concurrency limits enforced when they're due, not when they're scheduled. For example, consider this job:
+```ruby
+class DeliverAnnouncementToContactJob < ApplicationJob
+  limits_concurrency to: 1, key: ->(contact) { contact.account }, duration: 5.minutes
+
+  def perform(contact)
+    # ...
+```
+
+If several jobs are enqueued like this:
+
+```ruby
+DeliverAnnouncementToContactJob.set(wait: 10.minutes).perform_later(contact)
+DeliverAnnouncementToContactJob.set(wait: 10.minutes).perform_later(contact)
+DeliverAnnouncementToContactJob.set(wait: 30.minutes).perform_later(contact)
+```
+
+The 3 jobs will go into the scheduled queue and will wait there until they're due. Then, 10 minutes after, the first two jobs will be enqueued and the second one most likely will be blocked because the first one will be running first. Then, assuming the jobs are fast and finish in a few seconds, when the third job is due, it'll be enqueued normally.
+
+Normally scheduled jobs are enqueued in batches, but with concurrency controls, jobs need to be enqueued one by one. This has an impact on performance, similarly to the impact of concurrency controls in bulk enqueuing. Read below for more details. I'd generally advise against mixing concurrency controls with waiting/scheduling in the future.
+
 ### Performance considerations
 
 Concurrency controls introduce significant overhead (blocked executions need to be created and promoted to ready, semaphores need to be created and updated) so you should consider carefully whether you need them. For throttling purposes, where you plan to have `limit` significantly larger than 1, I'd encourage relying on a limited number of workers per queue instead. For example:

data/Rakefile

@@ -8,14 +8,36 @@ load "rails/tasks/engine.rake"
 load "rails/tasks/statistics.rake"
 
 require "bundler/gem_tasks"
+require "rake/tasklib"
 
-def databases
-  %w[ mysql postgres sqlite ]
-end
+class TestHelpers < Rake::TaskLib
+  def initialize(databases)
+    @databases = databases
+    define
+  end
 
-task :test do
-  databases.each do |database|
+  def define
+    desc "Run tests for all databases (mysql, postgres, sqlite)"
+    task :test do
+      @databases.each { |database| run_test_for_database(database) }
+    end
+
+    namespace :test do
+      @databases.each do |database|
+        desc "Run tests for #{database} database"
+        task database do
+          run_test_for_database(database)
+        end
+      end
+    end
+  end
+
+  private
+
+  def run_test_for_database(database)
     sh("TARGET_DB=#{database} bin/setup")
     sh("TARGET_DB=#{database} bin/rails test")
   end
 end
+
+TestHelpers.new(%w[ mysql postgres sqlite ])

data/app/models/solid_queue/job.rb

@@ -30,6 +30,7 @@ module SolidQueue
 
         create_from_active_job(active_job).tap do |enqueued_job|
           active_job.provider_job_id = enqueued_job.id if enqueued_job.persisted?
+          active_job.successfully_enqueued = enqueued_job.persisted?
         end
       end
 

data/app/models/solid_queue/recurring_task.rb

@@ -130,7 +130,6 @@ module SolidQueue
             active_job.run_callbacks(:enqueue) do
               Job.enqueue(active_job)
             end
-            active_job.successfully_enqueued = true
           end
         end
       end

data/lib/solid_queue/version.rb

@@ -1,3 +1,3 @@
 module SolidQueue
-  VERSION = "1.2.0"
+  VERSION = "1.2.1"
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: solid_queue
 version: !ruby/object:Gem::Version
-  version: 1.2.0
+  version: 1.2.1
 platform: ruby
 authors:
 - Rosa Gutierrez
 autorequire:
 bindir: bin
 cert_chain: []
-date: 2025-07-11 00:00:00.000000000 Z
+date: 2025-07-23 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: activerecord
@@ -84,14 +84,14 @@ dependencies:
   name: thor
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
         version: 1.3.1
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
         version: 1.3.1
 - !ruby/object:Gem::Dependency