sidekiq-batch-jobs 0.3.1 → 0.4.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 8f4d7393e0ca05c738c5714bd6cf5da53a0d52995d52b37560a5e6385cb88ff6
-  data.tar.gz: dfac8100fb929a8f97268bcc8f40c229e1753b0f43921d0a523ec14137525681
+  metadata.gz: c2fb395443c88a5e18c67c1689b97710f137447909fcb7892ece8f178c235ce8
+  data.tar.gz: 8554f4ca87f6785a6d61cb8170af63621782c5aeb9d3e92ae2cfbc9e231ea43b
 SHA512:
-  metadata.gz: 1a91c9a60b67597c4535f435c349a76dcfe75820e831def7e8085798a8c3be02e06e309082d5f1afef4a0221ff05a3d453e9b855f088b4530eaff006d31e170c
-  data.tar.gz: 1b1a1180879ecbda260d36763c087705e93e7dfbd867203d61c9ba3b8ba2b4e1787df1f31c5337940a4f9ab9e846cb9aacf3fdbf186f3cbbdf3c5525789b0146
+  metadata.gz: d2e5630d1411ec8f692a8e1f1cb386b4c1e0d3ba8f3d04b13414f06eeeaf28fb8128bea6dc81d40286afcc7c0ac6a1d4ac0bc6a70441f9ad4b44025dcc61788f
+  data.tar.gz: 3fa57b6c628c226b258580f2b60a3d68c53088153a9efc7410c74b0c90619470359f0526c7101f5ea1384efa6421f76bf3c0ad0949c53a9453f429b84c785220

data/CHANGELOG.md

@@ -5,6 +5,78 @@ All notable changes to this project are documented here.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.4.0] - 2026-09-22
+
+A support-window release. No behaviour changes, no schema change, and no API change beyond one
+shim that the new floor makes dead.
+
+### Breaking
+
+- **Rails 6.1, 7.0 and 7.1 are no longer supported.** The gemspec now requires
+  `activerecord >= 7.2, < 9`. Nothing in the gem stopped working on those versions, they are
+  simply no longer tested against, and with 8.1 shipped they are all past Rails' own security
+  support. Stay on 0.3.1 if you need them; it is unaffected by this release.
+- **Ruby 3.0 is out, and the floor is 3.1.** Not our choice to make: Rails 7.2 requires
+  Ruby >= 3.1, so supporting one sets the other.
+- **`Sidekiq::Batch::Jobs::EnumCompat` is gone.** It existed only to bridge Rails 6.1's
+  hash-form `enum` against the positional form 7.0 introduced, and with 7.2 as the floor every
+  supported Rails takes the same branch. The models now call `enum` directly. Nothing
+  downstream changes, because the generated surface is identical: `.statuses`, the
+  `pending_status?` predicates and the `pending_status` scopes are all still there. Only a host
+  that referenced the module by name is affected, which it had no reason to.
+
+### Added
+
+- A `rails-8.1` lane, so the newest Rails series is actually covered rather than merely
+  permitted by the `< 9` ceiling.
+- **Callbacks may now be ActiveJob classes.** `batch.on(:complete, SomeApplicationJob)` works
+  alongside the Sidekiq workers that were previously the only option. In an application that is
+  otherwise all ActiveJob, reaching for `ApplicationJob` was the natural move and the one thing
+  that did not work, silently: the announcement raised `NoMethodError` on `perform_async`, which
+  was swallowed into an alert that then repeated on every reaper run until grooming.
+
+  The payload is built and pushed directly rather than by calling `perform_later`, because
+  Sidekiq's ActiveJob adapter declares `enqueue_after_transaction_commit?` and would defer the
+  push until after the claim had committed. That would leave a claimed event with nothing sent
+  and nothing to retry it, since a spent claim is what stops the orphaned-callback reaper
+  looking again. The cost is that ActiveJob's enqueue callbacks do not run for batch callbacks.
+  `perform`, `around_perform` and `retry_on` are unaffected.
+- `require "sidekiq/batch/jobs/rspec"`, which is the test-suite wiring every host was writing by
+  hand. It sets the enrolment transaction baseline that transactional fixtures otherwise trip,
+  and registers the server middleware that `Sidekiq::Testing` never gets from `install!`. The
+  second is the one worth shipping: without it inline jobs run, nothing marks their rows
+  complete, and batches never finish, with nothing raised to say why. The gem's own suite now
+  uses this file rather than its own copy, so it cannot rot unnoticed.
+- `SidekiqBatch#on` rejects a class that can be neither `perform_async`ed nor `perform_later`ed,
+  naming both interfaces. Registration is where that is cheap to catch.
+
+### Changed
+
+- The lanes are now `rails-7.2` (Ruby 3.1.7, Sidekiq 7.3), `rails-8.0` and `rails-8.1` (both
+  Ruby 3.4.6, Sidekiq 8). `rails-7.2` carries the most weight: it is the only lane on Ruby 3.1
+  and the only one on Sidekiq 7, so it alone proves the bottom of both declared ranges.
+- The development image moved from Ruby 3.0.7 to 3.1.7, which also moves its base from Debian
+  bullseye to bookworm. Worth knowing because the bullseye apt mirror had begun 404ing on
+  `git`, which left `bin/setup` and `bin/test` unable to build an image at all. Both work
+  again.
+- `rake audit` now hard-fails on both Rails 8 lanes, where before only one lane was held to
+  that. `rails-7.2` still soft-fails, for a reason that has nothing to do with Rails: it runs
+  Ruby 3.1, which caps nokogiri at 1.18.10 because 1.19 requires 3.2, and those advisories have
+  no version to move to. nokogiri is test-only, reaching the lockfile through actionview, so
+  the gem declares no runtime dependency on it and nothing reaches a host application.
+- Development dependencies now cap `json` below 3.0. The September 2026 release dropped the
+  `quirks_mode` keyword from `generate` and changed `parse`'s arity, which breaks every Rails
+  series this gem supports. Deliberately in the Gemfile rather than the gemspec: it is Rails'
+  incompatibility to resolve, and capping a host application's json for them would be
+  overreach.
+
+### Upgrading from 0.3.1
+
+Nothing to run. On Rails 7.2+ and Ruby 3.1+, `bundle update sidekiq-batch-jobs` is the whole
+upgrade: no migration, no configuration change, no API change.
+
+On Rails 7.1 or older, Bundler will simply decline the upgrade and leave you on 0.3.1.
+
 ## [0.3.1] - 2026-09-08
 
 ### Fixed

data/README.md

@@ -4,7 +4,7 @@ Batch tracking and completion callbacks for Sidekiq, backed by ActiveRecord (Pos
 
 A hand-rolled alternative to Sidekiq Pro batches. Group a set of `perform_async` calls into a batch, persist their state in the database, and fire callback workers when the batch finishes. You decide what counts as a failure: one bad job, all of them, or some tolerance in between.
 
-Tested against Ruby 3.0–3.4, Rails 6.1–8.0, Sidekiq 7–8.
+Tested against Ruby 3.1–3.4, Rails 7.2–8.1, Sidekiq 7–8.
 
 ## Contents
 
@@ -215,11 +215,61 @@ calls. Usually that is merely surprising. `retry_on` is worse: ActiveJob catches
 itself and queues a *new* job, so Sidekiq only ever sees the original succeed. The batch marks
 that row complete and can report success while the work is still failing and retrying.
 
+If you do enrol an ActiveJob, control its retries with `sidekiq_options` rather than
+`retry_on`, and the batch reads them correctly:
+
+```ruby
+class RescoreJob < ApplicationJob
+  # Read by Sidekiq, not by ActiveJob.
+  sidekiq_options retry: 5
+
+  def perform(entry_id)
+    Entry.find(entry_id).rescore!
+  end
+end
+
+batch.jobs { RescoreJob.perform_later(entry.id) }
+```
+
+The middleware decides whether a failure is a job's last attempt from `job["retry"]` in the
+Sidekiq payload, and Sidekiq's client merges the wrapped ActiveJob class's `sidekiq_options`
+into that payload as it is pushed. So `retry: 5` arrives as the Integer `5`, exactly as it
+would for a plain worker, and the row is only marked failed on the final attempt. `retry: false`
+arrives as `false` and means "no retries, so this attempt is the last one". Omitting
+`sidekiq_options` entirely gives `true`, which falls back to Sidekiq's configured `max_retries`
+(25 by default). All three are handled, and this holds across every Sidekiq version the gem
+supports.
+
 Beyond that you don't have to think about jid tracking, race conditions, or middleware
 ordering. You just write the block.
 
 ### What a callback worker receives
 
+**A callback can be a Sidekiq worker or an ActiveJob class.** Either is fine, and an
+`ApplicationJob` subclass works exactly as you would expect:
+
+```ruby
+batch.on(:complete, RebuildLeaderboardCacheWorker)   # include Sidekiq::Job
+batch.on(:failure,  AlertOpsJob)                     # < ApplicationJob
+```
+
+Anything else is refused where you register it, rather than failing later:
+
+```ruby
+batch.on(:complete, SomePlainClass)
+# => ArgumentError: SomePlainClass cannot be a batch callback: it answers to neither
+#    `perform_async` (from `Sidekiq::Job`) nor `perform_later` (from `ActiveJob::Base`) ...
+```
+
+One caveat on ActiveJob callbacks. The gem builds the Sidekiq payload and pushes it itself
+rather than calling `perform_later`, because Sidekiq's ActiveJob adapter defers a
+`perform_later` until after the surrounding transaction commits, and the announcement has to
+enqueue inside the transaction that claims the event. Deferring it would let the claim commit
+with nothing sent, which nothing retries, because a spent claim is exactly what stops the
+reaper looking again. The consequence for you is that ActiveJob's **enqueue** callbacks
+(`before_enqueue` and friends) do not run for a batch callback. Everything after that point,
+including `perform`, `around_perform` and `retry_on`, is untouched.
+
 Every callback gets one argument: the batch id. From there it can inspect the batch's full state:
 
 ```ruby
@@ -387,6 +437,50 @@ different from the event sitting right beside it.
 Batches do not finish by themselves in a test suite, and it is worth knowing why before you go
 looking for the bug.
 
+**Start with the shipped wiring.** One require covers both of the things below that every
+suite needs:
+
+```ruby
+# spec/rails_helper.rb
+require "sidekiq/batch/jobs/rspec"
+```
+
+That sets the enrolment transaction baseline around each example, and registers the server
+middleware that `Sidekiq::Testing` does not otherwise get. Both are explained below, because
+they are worth understanding and doing by hand is perfectly fine.
+
+**Transactional fixtures look exactly like a caller-opened transaction.** Rails turns
+`use_transactional_fixtures` on by default, which wraps every example in a transaction that is
+never committed. `jobs {}` refuses to run inside a transaction the caller opened, so in a
+standard suite every single call raises `TransactionError` before it enrols anything.
+
+Tell the guard which depth counts as "no transaction" rather than turning it off:
+
+```ruby
+# spec/rails_helper.rb
+RSpec.configure do |config|
+  config.before do
+    Thread.current[SidekiqBatch::BatchEnrollmentContext::TXN_BASELINE] =
+      ActiveRecord::Base.connection.open_transactions
+  end
+
+  config.after do
+    Thread.current[SidekiqBatch::BatchEnrollmentContext::TXN_BASELINE] = nil
+  end
+end
+```
+
+Recording the depth keeps the guard doing its job: a transaction your test opens *on top of*
+the fixture one still raises, which is the case actually worth catching. Clearing it afterwards
+stops a stale baseline from hiding a real transaction in a later example. This gem's own suite
+does exactly this, in `spec/support/sidekiq_batch.rb`. Minitest wraps examples the same way, so
+the same pair works from `setup` and `teardown`.
+
+The guard is not arbitrary: enrolment rows have to be committed before their jobs reach Redis,
+or a worker can start before its row is visible, and a rollback can discard the row for a job
+that is already running. Disabling the check instead of baselining it gives up that guarantee
+in the suite that is meant to be proving it.
+
 **In fake mode** (Sidekiq's default) pushed jobs go into an array instead of running, so the
 enrollment rows stay `pending` and the batch stays `running`. That is usually what you want:
 assert on `batch.total_jobs` and the rows, then drive the outcome yourself.
@@ -402,12 +496,17 @@ batch.attempt_completion!            # now it is `succeeded` and the callbacks a
 ```
 
 **In inline mode** jobs run at push time, but Sidekiq's inline path uses its own middleware
-chain, which is empty by default. Add this gem's middleware to it or nothing will be tracked:
+chain, which is empty by default. `install!` will not fill it for you, because it only adds
+the server middleware when `Sidekiq.server?` is true, which never happens under RSpec. Add it
+yourself, or take the require above, which does this:
 
 ```ruby
 Sidekiq::Testing.server_middleware { |chain| chain.add(SidekiqBatch::Middleware) }
 ```
 
+Without it nothing raises. Inline jobs run, no row is ever marked complete, and batches simply
+never finish, so callbacks never fire and the suite quietly proves nothing.
+
 Even then, an inline job runs *while the block is still open*, so anything it enqueues joins
 the batch. Fake mode avoids that entirely, which is why this gem's own suite uses it.
 
@@ -545,14 +644,14 @@ Run `bin/setup` again whenever the `Dockerfile`, the `Gemfile` or `Appraisals` c
 ### Running things
 
 ```bash
-bin/test                                        # rails-6.1, the default lane
+bin/test                                        # rails-7.2, the default lane
 bin/test spec/models                            # arguments pass through to rspec
 bin/test spec/models/sidekiq_batch_spec.rb:42   # including a single example
-bin/test --lane rails-8.0                       # one specific lane
+bin/test --lane rails-8.1                       # one specific lane
 bin/test --all                                  # every lane, in order
 
 bin/shell                                       # interactive shell in the default lane
-bin/shell rails-8.0                             # or in another one
+bin/shell rails-8.1                             # or in another one
 ```
 
 Rake tasks run inside a lane rather than on your host, so reach them through `bin/shell`:
@@ -565,28 +664,27 @@ bundle exec rake audit      # this lane's lockfile against the ruby-advisory-db
 
 `audit` sits outside the default task because it needs network access.
 
-> **Expect advisories on the older lanes.** The `rails-6.1` and `rails-7.1` lockfiles already
-> hold the newest release in those series (6.1.7.10, 7.1.6), and both series are past security
-> support, so roughly 20 advisories each have no version to move to. nokogiri is stuck for the
-> same reason: 1.18+ requires Ruby >= 3.1. CI audits every lane but only *fails* on `rails-8.0`,
-> which is clean. Green CI does not mean "no known advisories on Rails 6.1".
+> **Expect nokogiri advisories on `rails-7.2`.** That lane runs Ruby 3.1, and nokogiri 1.19
+> requires 3.2, so it is held at 1.18.10 with advisories that have no version to move to.
+> nokogiri arrives through actionview and is test-only: the gem declares no runtime dependency
+> on it, so none of this reaches a host application. CI audits every lane but only *fails* on
+> `rails-8.0` and `rails-8.1`, both of which are clean.
 
 ### The three lanes
 
 | Lane | Ruby | Rails | Sidekiq | Why it exists |
 | --- | --- | --- | --- | --- |
-| `rails-6.1` | 3.0.7 | 6.1.7 | 7.3.10 | The app this gem was extracted from |
-| `rails-7.1` | 3.0.7 | 7.1 | 7.3 | Exercises `EnumCompat`'s `>= 7` branch |
-| `rails-8.0` | 3.4.6 | 8.0 | 8.x | ActiveRecord 8 removed the hash form of `enum` |
+| `rails-7.2` | 3.1.7 | 7.2 | 7.3 | The floor: oldest supported Rails, Ruby and Sidekiq |
+| `rails-8.0` | 3.4.6 | 8.0 | 8.0 | ActiveRecord 8 removed the hash form of `enum` |
+| `rails-8.1` | 3.4.6 | 8.1 | 8.1 | The newest supported pairing, and the `< 9` ceiling |
 
-`rails-6.1` and `rails-8.0` are the two that matter most. No single lane can cover both
-branches of the `enum` shim, because 6.1 accepts only the hash form and 8.0 only the
-positional one.
+`rails-7.2` is the one carrying the most weight. It is the only lane running Ruby 3.1 and the
+only lane running Sidekiq 7, so it alone proves the bottom of both declared ranges.
 
 **Two images, and Ruby is why.** Appraisal varies gem versions; it cannot vary Ruby. Rails 8
-and Sidekiq 8 both require Ruby >= 3.2, so `rails-8.0` cannot run on the Ruby 3.0.7 image that
-matches the extraction target. `docker-compose.yml` pairs each lane with a Ruby that can run
-it, and CI mirrors that pairing.
+and Sidekiq 8 both require Ruby >= 3.2, so neither 8 lane can run on the Ruby 3.1.7 image that
+`rails-7.2` needs. `docker-compose.yml` pairs each lane with a Ruby that can run it, and CI
+mirrors that pairing.
 
 Postgres and Redis come up through compose and are gated on healthchecks, so there is no wait
 loop to care about. Postgres data is on tmpfs, so `docker compose down` any time. The suite

data/app/models/sidekiq_batch/announcement.rb

@@ -78,7 +78,9 @@ class SidekiqBatch
       SidekiqBatch.transaction do
         next unless claim!(event)
 
-        worker.perform_async(batch.id)
+        # Inside the transaction on purpose: see CallbackTarget for why an
+        # ActiveJob callback cannot be sent with `perform_later`.
+        CallbackTarget.enqueue(worker, batch.id)
 
         fired = Fired.new(event: event, job_class: job_class_name)
       end

data/app/models/sidekiq_batch/callback_target.rb

@@ -0,0 +1,111 @@
+# frozen_string_literal: true
+
+class SidekiqBatch
+  # Turns a registered callback class into an enqueued job.
+  #
+  # Two shapes are accepted, told apart by the enqueue method each answers to:
+  # including `Sidekiq::Job` defines `perform_async` and never `perform_later`,
+  # while `ActiveJob::Base` defines exactly the reverse. Nothing here inspects
+  # ancestors, so a class that provides either interface some other way works
+  # too.
+  module CallbackTarget
+    class << self
+      # Whether {.enqueue} could send this class. Used by `SidekiqBatch#on` so a
+      # class that can never be delivered is rejected where it is registered.
+      def supported?(job_class)
+        sidekiq_job?(job_class) || active_job?(job_class)
+      end
+
+      # Runs inside the transaction that claims the event, which is the whole
+      # constraint on this method: neither branch may defer its push past that
+      # commit. See {.push_active_job}.
+      def enqueue(job_class, batch_id)
+        return job_class.perform_async(batch_id) if sidekiq_job?(job_class)
+
+        push_active_job(job_class, batch_id)
+      end
+
+      # Registration is where an undeliverable callback is cheap to catch. Left
+      # to the announcement it costs a great deal more: the push raises, the
+      # claim rolls back, `fire` swallows it into an alert, and the unclaimed
+      # event keeps the batch in the orphaned-callback scope, alerting again on
+      # every reaper run until grooming deletes it.
+      def validate!(job_class)
+        klass = job_class.is_a?(Module) ? job_class : job_class.to_s.safe_constantize
+
+        # A name that does not resolve here is left alone rather than guessed
+        # at: in a Rails application it may simply not be autoloaded yet, and
+        # the announcement resolves it again when it fires.
+        return if klass.nil?
+        return if supported?(klass)
+
+        raise ArgumentError, unsupported_message(klass)
+      end
+
+      def unsupported_message(job_class)
+        if job_class.respond_to?(:perform_later)
+          "#{job_class} is an ActiveJob class, but Sidekiq's ActiveJob adapter is not loaded, " \
+            "so there is no wrapper to enqueue it through. Set " \
+            "`config.active_job.queue_adapter = :sidekiq`, or register a class that includes " \
+            "`Sidekiq::Job` instead."
+        else
+          "#{job_class} cannot be a batch callback: it answers to neither `perform_async` " \
+            "(from `Sidekiq::Job`) nor `perform_later` (from `ActiveJob::Base`), so there is no " \
+            "way to enqueue it. Callbacks are enqueued by this gem, not called inline."
+        end
+      end
+
+      private
+
+      def sidekiq_job?(job_class)
+        job_class.respond_to?(:perform_async)
+      end
+
+      # The adapter is what supplies the wrapper the payload is pushed as, so
+      # without it an ActiveJob cannot be delivered through Sidekiq at all.
+      def active_job?(job_class)
+        job_class.respond_to?(:perform_later) && !active_job_wrapper.nil?
+      end
+
+      # The wrapper the host's own adapter would use, rather than a second one
+      # that merely happens to work. Rails ships a SidekiqAdapter of its own,
+      # and Sidekiq replaces it from 8.0, aliasing `JobWrapper` to its version.
+      # On Rails 7.2 with Sidekiq 7.3 the two are different classes, so reading
+      # it through the adapter is what keeps the payload identical to the one
+      # `perform_later` would have pushed on whichever pairing the host runs.
+      def active_job_wrapper
+        if defined?(::ActiveJob::QueueAdapters::SidekiqAdapter::JobWrapper)
+          ::ActiveJob::QueueAdapters::SidekiqAdapter::JobWrapper
+        elsif defined?(::Sidekiq::ActiveJob::Wrapper)
+          ::Sidekiq::ActiveJob::Wrapper
+        end
+      end
+
+      # Deliberately not `perform_later`.
+      #
+      # Sidekiq's ActiveJob adapter declares `enqueue_after_transaction_commit?`,
+      # so `perform_later` hands the push to an after-commit hook rather than
+      # running it here. The claim would then commit first, and a crash in that
+      # window leaves the event claimed with nothing sent. Nothing recovers
+      # that: a spent claim is exactly what stops the orphaned-callback reaper
+      # looking at the batch again. Pushing the wrapper payload ourselves keeps
+      # the enqueue inside the claim transaction, where the existing guarantee
+      # holds, which is that a rollback un-claims the event and the reaper
+      # retries it.
+      #
+      # The payload is the one the adapter builds. The cost of not going through
+      # ActiveJob is that its enqueue callbacks (`before_enqueue` and friends)
+      # do not run.
+      def push_active_job(job_class, batch_id)
+        job = job_class.new(batch_id)
+
+        ::Sidekiq::Client.push(
+          "class"   => active_job_wrapper,
+          "wrapped" => job_class,
+          "queue"   => job.queue_name,
+          "args"    => [job.serialize]
+        )
+      end
+    end
+  end
+end

data/app/models/sidekiq_batch.rb

@@ -22,8 +22,6 @@
 #  updated_at        :datetime         not null
 #
 class SidekiqBatch < ::Sidekiq::Batch::Jobs.base_class
-  extend ::Sidekiq::Batch::Jobs::EnumCompat
-
   # `complete` fires whatever the outcome; `success` and `failure` name it.
   # Three rather than two, so "always do X, and separately alert on failure"
   # needs no duplicate registration. Same vocabulary as Sidekiq Pro.
@@ -34,7 +32,11 @@ class SidekiqBatch < ::Sidekiq::Batch::Jobs.base_class
   # `succeeded`, not `complete`: `:complete` is the event that fires whatever
   # the outcome, so a status of that name would mean the opposite of the event
   # firing beside it.
-  status_enum(pending: 0, running: 1, succeeded: 2, failed: 3)
+  #
+  # Positional, with `suffix:`, because ActiveRecord 8 accepts no other form.
+  # The suffix is what keeps `failed_status?` clear of the `failure` callback
+  # vocabulary sitting beside it.
+  enum :status, { pending: 0, running: 1, succeeded: 2, failed: 3 }, suffix: :status
 
   has_many :sidekiq_batch_jobs, dependent: :delete_all
 
@@ -90,6 +92,8 @@ class SidekiqBatch < ::Sidekiq::Batch::Jobs.base_class
             "cannot register a #{event_str} callback on a batch that has already finished (#{status})"
     end
 
+    CallbackTarget.validate!(job_class)
+
     self.callbacks = callbacks.merge(event_str => job_class.to_s)
 
     save!

data/app/models/sidekiq_batch_job.rb

@@ -16,9 +16,8 @@
 #  sidekiq_batch_id :bigint           not null
 #
 class SidekiqBatchJob < ::Sidekiq::Batch::Jobs.base_class
-  extend ::Sidekiq::Batch::Jobs::EnumCompat
-
-  status_enum(pending: 0, complete: 1, failed: 2)
+  # Positional, with `suffix:`, because ActiveRecord 8 accepts no other form.
+  enum :status, { pending: 0, complete: 1, failed: 2 }, suffix: :status
 
   belongs_to :sidekiq_batch
 

data/lib/sidekiq/batch/jobs/rspec.rb

@@ -0,0 +1,46 @@
+# frozen_string_literal: true
+
+require "rspec/core"
+
+# Test-suite wiring, in one require:
+#
+#   # spec/rails_helper.rb
+#   require "sidekiq/batch/jobs/rspec"
+#
+# Both halves are mechanical, identical in every host, and awkward to work out
+# from the symptom. Requiring this is optional; doing it by hand is fine.
+RSpec.configure do |config|
+  # Transactional fixtures wrap each example in a transaction that is never
+  # committed, which is indistinguishable from one the caller opened, so
+  # without a baseline every `jobs {}` call in the suite raises
+  # TransactionError before enrolling anything.
+  #
+  # Recording the harness's depth rather than disabling the check keeps the
+  # guard live: a transaction the example opens on top of the fixture one still
+  # raises, which is the case worth catching. Read from the gem's own model, so
+  # it is the same connection the guard measures.
+  config.before do
+    Thread.current[::SidekiqBatch::BatchEnrollmentContext::TXN_BASELINE] =
+      ::SidekiqBatchJob.connection.open_transactions
+  end
+
+  # Cleared so a stale baseline cannot hide a real transaction in a later
+  # example that runs outside this hook.
+  config.after do
+    Thread.current[::SidekiqBatch::BatchEnrollmentContext::TXN_BASELINE] = nil
+  end
+
+  # `install!` only adds the server middleware when `Sidekiq.server?` is true,
+  # which it never is under RSpec. Without this, inline jobs run and nothing
+  # marks their rows complete, so batches never finish and callbacks never
+  # fire, with nothing raised to say why. That silence is the reason this is
+  # worth shipping rather than documenting.
+  #
+  # In `before(:suite)` so the host can require its Sidekiq testing API either
+  # side of this file. Harmless under fake mode, where no job runs.
+  config.before(:suite) do
+    next unless defined?(::Sidekiq::Testing)
+
+    ::Sidekiq::Testing.server_middleware { |chain| chain.add(::SidekiqBatch::Middleware) }
+  end
+end

data/lib/sidekiq/batch/jobs/version.rb

@@ -3,7 +3,7 @@
 module Sidekiq
   module Batch
     module Jobs
-      VERSION = "0.3.1"
+      VERSION = "0.4.0"
     end
   end
 end

data/lib/sidekiq/batch/jobs.rb

@@ -3,7 +3,6 @@
 require "sidekiq"
 require_relative "jobs/version"
 require_relative "jobs/schema"
-require_relative "jobs/enum_compat"
 require_relative "jobs/failure_policy"
 require_relative "jobs/configuration"
 require_relative "jobs/engine" if defined?(Rails::Engine)

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: sidekiq-batch-jobs
 version: !ruby/object:Gem::Version
-  version: 0.3.1
+  version: 0.4.0
 platform: ruby
 authors:
 - Douglas Greyling
@@ -15,7 +15,7 @@ dependencies:
     requirements:
     - - ">="
       - !ruby/object:Gem::Version
-        version: '6.1'
+        version: '7.2'
     - - "<"
       - !ruby/object:Gem::Version
         version: '9'
@@ -25,7 +25,7 @@ dependencies:
     requirements:
     - - ">="
       - !ruby/object:Gem::Version
-        version: '6.1'
+        version: '7.2'
     - - "<"
       - !ruby/object:Gem::Version
         version: '9'
@@ -35,7 +35,7 @@ dependencies:
     requirements:
     - - ">="
       - !ruby/object:Gem::Version
-        version: '6.1'
+        version: '7.2'
     - - "<"
       - !ruby/object:Gem::Version
         version: '9'
@@ -45,7 +45,7 @@ dependencies:
     requirements:
     - - ">="
       - !ruby/object:Gem::Version
-        version: '6.1'
+        version: '7.2'
     - - "<"
       - !ruby/object:Gem::Version
         version: '9'
@@ -88,6 +88,7 @@ files:
 - app/models/sidekiq_batch/abandoned_enrollment_reaper.rb
 - app/models/sidekiq_batch/announcement.rb
 - app/models/sidekiq_batch/batch_enrollment_context.rb
+- app/models/sidekiq_batch/callback_target.rb
 - app/models/sidekiq_batch/client_middleware.rb
 - app/models/sidekiq_batch/completion_query.rb
 - app/models/sidekiq_batch/groomer_worker.rb
@@ -106,8 +107,8 @@ files:
 - lib/sidekiq/batch/jobs.rb
 - lib/sidekiq/batch/jobs/configuration.rb
 - lib/sidekiq/batch/jobs/engine.rb
-- lib/sidekiq/batch/jobs/enum_compat.rb
 - lib/sidekiq/batch/jobs/failure_policy.rb
+- lib/sidekiq/batch/jobs/rspec.rb
 - lib/sidekiq/batch/jobs/schema.rb
 - lib/sidekiq/batch/jobs/version.rb
 homepage: https://github.com/douglasgreyling/sidekiq-batch-jobs
@@ -124,7 +125,7 @@ required_ruby_version: !ruby/object:Gem::Requirement
   requirements:
   - - ">="
     - !ruby/object:Gem::Version
-      version: 3.0.0
+      version: 3.1.0
 required_rubygems_version: !ruby/object:Gem::Requirement
   requirements:
   - - ">="

data/lib/sidekiq/batch/jobs/enum_compat.rb

@@ -1,29 +0,0 @@
-# frozen_string_literal: true
-
-module Sidekiq
-  module Batch
-    module Jobs
-      # ActiveRecord's `enum` signature moved twice inside the range this gem
-      # supports, and no single call works across all of it:
-      #
-      #   6.1      def enum(definitions)                       hash only, `_suffix:`
-      #   7.0-7.2  def enum(name = nil, values = nil, **opts)  either form
-      #   8.0      def enum(name, values = nil, **opts)        positional, `suffix:`
-      #
-      # So 6.1 rejects the modern call and 8.0 rejects the legacy one. Both forms
-      # generate an identical surface (`.statuses`, the `pending_status?`
-      # predicates, the `pending_status` scopes), so which branch a given Rails
-      # takes is invisible to everything downstream.
-      module EnumCompat
-        # @param values [Hash{Symbol => Integer}] status name => column value
-        def status_enum(values)
-          if ::ActiveRecord::VERSION::MAJOR >= 7
-            enum :status, values, suffix: :status
-          else
-            enum status: values, _suffix: :status
-          end
-        end
-      end
-    end
-  end
-end