solid_queue 1.7.2 writes its concurrency lock into a job's arguments, failing spec 055's Retry now check (#277) #283

Dependabot PR #277 bumps solid_queue from 1.7.0 to 1.7.2. Its RSpec shard 3/4 fails one example, so the PR is held, not merged (run 42824336382):

rspec ./spec/models/catalog/operation/queue_spec.rb:123
# Catalog::Operation::Queue#run_now (spec 055 FR-2) makes a scheduled job ready,
# adding no job and leaving its Active Job id and arguments as they were
expected: {... "arguments" => {"arguments" => ["mtg", "m...", "scheduled_at" => "…", "timezone" => "UTC"}, "id" => 1}
     got: {... "arguments" => {"arguments" => ["mtg", "m...", "solid_queue_concurrency_lock" => {"limit" => 1, "semaphore_id" => 1}, "timezone" => "UTC"}, "id" => 1}

Cause. solid_queue 1.7.2 (rails/solid_queue#831) gives a concurrency-limited job's slot back only to the semaphore it came from. To know which semaphore that is, it records the semaphore in the job's stored arguments (solid_queue_concurrency_lock) when it dispatches the job. Catalog::RefreshJob uses limits_concurrency. So when Catalog::Operation::Queue#run_now ("Retry now", spec 055) dispatches a waiting retry, the gem now writes that key into the row. The example compares the whole stored arguments column with what it was before.

What's unchanged. The job's own Active Job arguments (arguments["arguments"], here ["mtg", "manual"]) and its Active Job id. No job is added, and the job still becomes ready with no scheduled or blocked execution. The gem changes its own bookkeeping, not the job.

For the maintainer to rule. Does spec 055 FR-2's "leaving its Active Job id and arguments as they were" mean:

• A (recommended): the Active Job arguments, meaning the job's id and arguments["arguments"]. Then the example compares those fields and ignores the gem's keys, the bump merges, and the area doc catalog-operations.md says which arguments FR-2 means. scheduled_at disappearing on dispatch would also be the gem's own bookkeeping.
• B: the whole stored column, as written. Then the app holds solid_queue at 1.7.0 (~> 1.7.0, < 1.7.2) until spec 055 is restated, and the 1.7.2 slot fix waits.

Check either way: that "Retry now" still respects limits_concurrency under 1.7.2 (a second refresh stays blocked while one holds the slot), and that its slot is given back to the same semaphore. The spec 015 and 055 examples for the admin catalog and jobs pages cover this.

🤖 Generated with Claude Code