Test that a job records the semaphore it created on MySQL, and correct the upgrade note

A plain read inside a REPEATABLE READ transaction can still see a
semaphore deleted after the transaction's snapshot, so without the
locking read the job would record that one. The test fails without it.

A slot that isn't given back comes back only when its semaphore expires,
and every job taking or giving back a slot for the same key pushes that
out, so on a busy key with a limit above 1 it may not come back for a
long time. Say so in UPGRADING instead of promising it comes back after
duration.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Author: rosa

UPGRADING.md

@@ -3,7 +3,7 @@ Jobs with [concurrency controls](README.md#concurrency-controls) now remember wh
 
 There's nothing to change or migrate. Jobs that got their slot before you upgrade have nothing recorded and give it back as before, so old and new versions can run side by side while you deploy.
 
-Solid Queue 2.0 will stop giving back slots that weren't recorded. Before upgrading to 2.0, let the concurrency-limited jobs that were ready or running when you upgraded to 1.7.2 finish. If any haven't, their slots stay taken until their semaphores expire, after `duration`, and then the jobs waiting for them are released as usual.
+Solid Queue 2.0 will stop giving back slots that weren't recorded. Before upgrading to 2.0, make sure the concurrency-limited jobs that were ready or running when you upgraded to 1.7.2 have finished. Otherwise their slots won't be given back: a slot like that only comes back when its semaphore expires, and every job that takes or gives back a slot for the same key pushes that expiry out by another `duration`, so on a busy key with a limit above 1 it can stay lost for as long as the key stays busy.
 
 # Upgrading to version 1.7.x
 This version introduces support for grouping jobs into batches, which needs new tables. Fresh installs get them with the base schema; existing installations need to copy the migration that adds them and run it:

test/models/solid_queue/semaphore_test.rb

@@ -9,6 +9,29 @@ class SolidQueue::SemaphoreTest < ActiveSupport::TestCase
     @result = JobResult.create!(queue_name: "default")
   end
 
+  test "a job records the semaphore it created, not one deleted after its transaction began" do
+    skip "Only MySQL reads a deleted row from the transaction's snapshot" unless SolidQueue::Record.connection.adapter_name.downcase.match?(/mysql|trilogy/)
+
+    NonOverlappingUpdateResultJob.perform_later(@result)
+    expired = SolidQueue::Semaphore.sole
+
+    SolidQueue::Record.transaction do
+      # Take the transaction's snapshot, as dispatching does when it reads its batch of jobs
+      SolidQueue::Job.count
+
+      # Maintenance deletes the expired semaphore from another connection
+      Thread.new do
+        SolidQueue::Record.connection_pool.with_connection { SolidQueue::Semaphore.where(id: expired.id).delete_all }
+      end.join
+
+      job = SolidQueue::Job.enqueue(NonOverlappingUpdateResultJob.new(@result))
+
+      assert job.ready?
+      assert_not_equal expired.id, job.concurrency_lock["semaphore_id"]
+      assert_equal SolidQueue::Semaphore.lock.find_by!(key: job.concurrency_key).id, job.concurrency_lock["semaphore_id"]
+    end
+  end
+
   test "wait acquires a row lock that blocks concurrent signal" do
     skip_on_sqlite