solid_queue-rate_limit 0.2.0 → 0.2.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 494dc86905183d3c7e43d93794d8529a7cee72b8039422137c98601c1c3f9793
-  data.tar.gz: 1926904a64c22e7bccc4f94066ffe308fd9a250700931ee5082b710fcb9dc607
+  metadata.gz: d53c3eda4b97f3203a12f8240e26b6242cd37a12350b9f06f0eee4d5aa8273fb
+  data.tar.gz: 201ea9c20ebcb5a3b3c37ecddf869d80e160b4c3b275a08c7c6fdd34b47e005c
 SHA512:
-  metadata.gz: 01afb44f70f3b73d76b29966687ee7da5876e41c9f70523f9c56f2f4741dcd2d88d6c0d1255a3ff70cd728e966fff93634b5e49f8f72b8626ada29b5272e1e68
-  data.tar.gz: b496de40a83ea8169222ddc5c2bc4e3f3900daeff6c55c71b7fc883e9e816ced70535bb10fc1cf70fe54e83c7af715424de3b873c3e69a2d9eb04632363c0517
+  metadata.gz: 84abc7c0357bad2e5904ccfb29985e53fe2c5a99c1c3ed6c70f921b0e1cdebe421ee3f7c52bff5c36f84494322000cec284b4fcef268e2a97f6a5510925f149e
+  data.tar.gz: 5feeb0a9e7bdee7325e973740d6ee0e27f3edad3f9f65f2932b9660aee54a34d18d2c58a6e33a87e59619b6ad53bae75524b68aed244ae6c89a48b6d3d770941

data/CHANGELOG.md

@@ -6,6 +6,14 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 
 ## [Unreleased]
 
+## [0.2.1] - 2026-11-06
+
+Allows Solid Queue 1.7.0 and 1.7.1 again, and CI now tests every 1.7 release and Solid Queue main. Upgrading from 0.2.0 takes no work. On Solid Queue before 1.7.2, a job that combines `limits_rate` with `limits_concurrency` can let one extra job run for its key, as in Solid Queue itself, so upgrade Solid Queue to 1.7.2 to avoid that.
+
+### Changed
+
+- Allows Solid Queue 1.7.0 and 1.7.1 again, as 0.1.0 did. Combining `limits_rate` with `limits_concurrency` works on them as Solid Queue does: a deferred job whose semaphore expired can let one more job than the limit run, which Solid Queue 1.7.2 fixes. CI tests each 1.7 release and Solid Queue main, and runs each Ruby with one Rails instead of with every Rails. ([#28](https://github.com/dtcristo/solid_queue-rate_limit/pull/28))
+
 ## [0.2.0] - 2026-11-06
 
 Adds a budget for each key with `key:` and `group:`, `limits_rate` and `limits_concurrency` on one class, a cleanup for idle budgets, and a retry for claims and dispatches that deadlock. Upgrading takes code changes but no migration: every `limits_rate` needs a `key:`, `to:` now includes the burst, and Solid Queue 1.7.2 is required. See [UPGRADING.md](https://github.com/dtcristo/solid_queue-rate_limit/blob/main/UPGRADING.md).
@@ -43,6 +51,7 @@ The first release adds `limits_rate`, so workers claim a job class's jobs no fas
 - Requires Solid Queue 1.7. ([#11](https://github.com/dtcristo/solid_queue-rate_limit/pull/11))
 - A README with recipes, the guarantee and a rule for picking `burst`, and [design notes](https://github.com/dtcristo/solid_queue-rate_limit/blob/main/docs/design.md). ([#13](https://github.com/dtcristo/solid_queue-rate_limit/pull/13))
 
-[Unreleased]: https://github.com/dtcristo/solid_queue-rate_limit/compare/v0.2.0...HEAD
+[Unreleased]: https://github.com/dtcristo/solid_queue-rate_limit/compare/v0.2.1...HEAD
+[0.2.1]: https://github.com/dtcristo/solid_queue-rate_limit/compare/v0.2.0...v0.2.1
 [0.2.0]: https://github.com/dtcristo/solid_queue-rate_limit/compare/v0.1.0...v0.2.0
 [0.1.0]: https://github.com/dtcristo/solid_queue-rate_limit/releases/tag/v0.1.0

data/README.md

@@ -72,7 +72,7 @@ Until the migration has run, everything else works as before, and enqueuing a jo
 
 Each process caches whether the table exists, so restart workers and web processes after you migrate. A deploy usually does that for you.
 
-The gem relies on private Solid Queue methods, so its gemspec allows one minor version of Solid Queue at a time, from 1.7.2.
+The gem relies on private Solid Queue methods, so its gemspec allows one minor version of Solid Queue at a time.
 
 To upgrade from an earlier version, follow [UPGRADING.md](UPGRADING.md). [CHANGELOG.md](CHANGELOG.md) lists what changed in each version.
 
@@ -369,12 +369,12 @@ It takes `batch_size:`, 500 by default, and `sleep_between_batches:`, like Solid
 | Dependency | Supported |
 | --- | --- |
 | Ruby | 3.2 and newer |
-| Rails | 7.1, 7.2, 8.0 and 8.1. CI also runs Rails main, except on Ruby 3.2 |
-| Solid Queue | 1.7.2 and newer within 1.7 |
+| Rails | 7.1, 7.2, 8.0 and 8.1. CI also runs Rails main |
+| Solid Queue | 1.7. CI runs 1.7.0, 1.7.1, 1.7.2 and main |
 | Database | MySQL, PostgreSQL and SQLite |
 | [Solid Queue Coalesce](https://github.com/dtcristo/solid_queue-coalesce) | Optional. CI tests 0.2 alongside |
 
-CI runs Ruby 3.2, 3.3, 3.4 and 4.0 against all three databases.
+CI runs each Rails and Solid Queue version against all three databases. Ruby 3.2 runs with Rails 7.1, 3.3 with 7.2, 3.4 with 8.0, and 4.0 with the rest.
 
 | Feature | Behaviour |
 | --- | --- |
@@ -430,7 +430,7 @@ Changing a limit and deploying applies to the next claim. A looser limit doesn't
 - A key longer than `solid_queue_rate_limits.key` allows, 255 characters on MySQL, raises `ActiveRecord::ValueTooLong` at enqueue, as an over-long concurrency key does. `perform_later` raises it wrapped in `SolidQueue::Job::EnqueueError`, and `perform_all_later` raises it as it is. PostgreSQL and SQLite have no limit.
 - A retry keeps the key its job was enqueued with. That covers a `retry_on` retry, a failed job you retry, and a retry after the arguments failed to deserialize.
 - A job keeps the key it was enqueued with while it waits, even if its class changes `key:` or `group:`. A job enqueued without a key, before its class declared a limit or by 0.1.0, uses the bare class-wide budget, `JobClass`, and gets the current key if it's retried.
-- `limits_rate` combines with `limits_concurrency`, in either order and through inheritance. A job over the rate gives its concurrency slot back and wakes the next blocked job for its key once the claim commits, and takes one again when the dispatcher brings it back, or is blocked. `limits_concurrency` with `on_conflict: :discard` raises `ArgumentError` with `limits_rate`, because a job that came back to a taken concurrency slot would be discarded. A job that still has a concurrency key after its class dropped `limits_concurrency` is checked like any other.
+- `limits_rate` combines with `limits_concurrency`, in either order and through inheritance. A job over the rate gives its concurrency slot back and wakes the next blocked job for its key once the claim commits, and takes one again when the dispatcher brings it back, or is blocked. `limits_concurrency` with `on_conflict: :discard` raises `ArgumentError` with `limits_rate`, because a job that came back to a taken concurrency slot would be discarded. A job that still has a concurrency key after its class dropped `limits_concurrency` is checked like any other. Before Solid Queue 1.7.2, a slot goes back to whichever semaphore its key has, so a deferred job whose semaphore expired can let one more job than the limit run, as a job that runs past its `duration` can in Solid Queue. 1.7.2 fixes both.
 - Without `group:`, the budget's key starts with the class's name. A job enqueued under an alias, such as a constant kept after a rename, keeps the key it was enqueued with, and shares the class's budget. On MySQL, two classes whose names differ only in case share one budget.
 - A job whose class doesn't load, or whose `class_name` isn't a job class, is claimed without a check and fails as it would without the gem.
 - A class that drops its limit has its waiting jobs claimed when they next check, at most 5 minutes later.

data/lib/solid_queue/rate_limit/version.rb

@@ -1,5 +1,5 @@
 module SolidQueue
   module RateLimit
-    VERSION = "0.2.0"
+    VERSION = "0.2.1"
   end
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: solid_queue-rate_limit
 version: !ruby/object:Gem::Version
-  version: 0.2.0
+  version: 0.2.1
 platform: ruby
 authors:
 - David Cristofaro
@@ -13,22 +13,16 @@ dependencies:
   name: solid_queue
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - ">="
-      - !ruby/object:Gem::Version
-        version: 1.7.2
-    - - "<"
+    - - "~>"
       - !ruby/object:Gem::Version
-        version: '1.8'
+        version: 1.7.0
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - ">="
-      - !ruby/object:Gem::Version
-        version: 1.7.2
-    - - "<"
+    - - "~>"
       - !ruby/object:Gem::Version
-        version: '1.8'
+        version: 1.7.0
 - !ruby/object:Gem::Dependency
   name: appraisal
   requirement: !ruby/object:Gem::Requirement