sidekiq-batch-jobs 0.3.0 → 0.3.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 148b48f6e660baae58a41a709b7b43010e8c7a1c29585368d9d624d23ce7bfa7
-  data.tar.gz: 5c606573cc3b223bd29b6843dc041cb8296c157b2d063b5e6d5055a736dca4b7
+  metadata.gz: 8f4d7393e0ca05c738c5714bd6cf5da53a0d52995d52b37560a5e6385cb88ff6
+  data.tar.gz: dfac8100fb929a8f97268bcc8f40c229e1753b0f43921d0a523ec14137525681
 SHA512:
-  metadata.gz: e6b4be14970f3567194ab9f8c81fe8dde1493308c83b73165fdcfb7291f2b3d67644d0ca97168f90816955a9de78479d81111abfdf4e42c1522fb4bc6d6be8a3
-  data.tar.gz: 4c910d40ef9a6a183541a18c8fb5d8ff2f8483ea26ad5b1cc22b2d611f0728cc3f26c36d494715a36d64b0bce24cb51683ba672e967e01dd692b750ee004e96e
+  metadata.gz: 1a91c9a60b67597c4535f435c349a76dcfe75820e831def7e8085798a8c3be02e06e309082d5f1afef4a0221ff05a3d453e9b855f088b4530eaff006d31e170c
+  data.tar.gz: 1b1a1180879ecbda260d36763c087705e93e7dfbd867203d61c9ba3b8ba2b4e1787df1f31c5337940a4f9ab9e846cb9aacf3fdbf186f3cbbdf3c5525789b0146

data/CHANGELOG.md

@@ -5,6 +5,33 @@ 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.3.1] - 2026-09-08
+
+### Fixed
+
+- **The reaper could fail jobs that were still running.** `JidIndex` read an executing job's id
+  as `work.payload["jid"]`, but `payload` holds the job as a JSON *string* rather than a nested
+  object, so that expression is String indexing: it finds the key *name* in the JSON and returns
+  the literal `"jid"`, for every job on the cluster. The live-jid index filled with a single
+  constant, no executing job was ever found in it, and `StuckJobReaper` marked rows orphaned
+  whose jobs were running perfectly well. Unrecoverable once it happened, since the job's own
+  `complete!` then finds the row no longer pending and leaves it failed.
+
+  Reaching it took a batch quiet for `stuck_after` (two hours by default), so the exposure was
+  long-running jobs, which is much of what batches are for. Present since 0.1.0.
+
+  The example covering this branch built its Redis fixture with a nested Hash, a shape no
+  Sidekiq version writes, so it passed throughout. It now writes the string form, alongside one
+  example pinning that shape and one asserting the literal `"jid"` never reaches the index.
+
+- **`JidIndex` raised `NoMethodError` on Sidekiq 7.0 to 7.2.** `WorkSet` yielded a raw Hash
+  until 7.3 and a `Sidekiq::Work` since, and the code called `#payload` on whatever it got. The
+  gemspec has always allowed `sidekiq >= 7.0`, and every CI lane resolves 7.3 or newer, so no
+  lane exercised the older shape. Both are now read through `Sidekiq::JobRecord`, which
+  normalises the string and hash forms the way `Sidekiq::Work#job` does.
+
+No schema change, so nothing to migrate.
+
 ## [0.3.0] - 2026-09-07
 
 ### Breaking

data/app/models/sidekiq_batch/jid_index.rb

@@ -34,12 +34,28 @@ class SidekiqBatch
     end
     private_class_method :add_sorted_sets
 
+    # Two shapes to survive here, and reading either one naively is silently
+    # wrong rather than loud.
+    #
+    # `payload` holds the job as a JSON *string*, not a nested object: the
+    # processor stores `{queue:, payload: jobstr, run_at:}`. So `payload["jid"]`
+    # is String indexing, which finds the key *name* in the JSON and returns the
+    # literal "jid" for every job on the cluster. The index fills with one
+    # constant, no executing job is ever found in it, and StuckJobReaper fails
+    # rows whose jobs are running perfectly well.
+    #
+    # The container around it moved too: WorkSet yielded a raw Hash until 7.3,
+    # and a Sidekiq::Work since. This gem supports both.
+    #
+    # JobRecord is Sidekiq's own reader for a job, and normalises the string and
+    # hash forms of a payload the same way `Sidekiq::Work#job` does.
     def self.add_executing(jids)
-      # `Sidekiq::Work` is a class, not a Hash — `#payload` is the supported
-      # accessor. Hash-style access still works through method_missing, but
-      # Sidekiq deprecated it.
-      ::Sidekiq::Workers.new.each do |_process_id, _thread_id, work|
-        jid = work.payload["jid"]
+      ::Sidekiq::WorkSet.new.each do |_process_id, _thread_id, work|
+        payload = work.respond_to?(:payload) ? work.payload : work["payload"]
+
+        next unless payload
+
+        jid = ::Sidekiq::JobRecord.new(payload).jid
 
         jids << jid if jid
       end

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

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

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: sidekiq-batch-jobs
 version: !ruby/object:Gem::Version
-  version: 0.3.0
+  version: 0.3.1
 platform: ruby
 authors:
 - Douglas Greyling