fix(solid_queue): don't perform the job twice when the guard clause raises

[antoinefink]

The bug

ActiveJobExtensions#perform_now used a method-level rescue, which in Ruby wraps the entire method body — including its own guard clause:

def perform_now
  return super unless Sentry.initialized? && using_solid_queue_adapter?  # <- also covered

  job_executed = false
  # ...instrumented call...
rescue => e
  raise if job_executed        # job_executed is nil here -> does not fire
  Sentry.sdk_logger.error(...) rescue nil
  super                        # <- performs the job a SECOND time
end

On the early-return path job_executed is still nil. Ruby registers a local from the lexical position of its assignment, so the rescue reads it as nil rather than raising NameError — which is why this failed silently. raise if job_executed never fires, the original exception is swallowed, and the fallback super performs the job a second time on the same instance.

Impact

Whenever the guard is false — any non-solid_queue adapter, or Sentry not initialized:

• executions reaches 2 for a single invocation
• side effects run twice: duplicate enqueues, doubled API calls, doubled logs
• the error that propagates is from the second run, masking the real one. An ActiveJob::Continuable job raises InvalidStepError on the replay, because its step state was already recorded

This hits every ActiveJob test in a host app (the test adapter reports queue_adapter_name == "test") and any environment on a different adapter — e.g. :inline on staging. Production on solid_queue was unaffected, since the guard passes there and the normal path runs.

The fix

Scope the rescue to a begin block around the instrumented section only, so the guard's own super is no longer covered by it. The fallback-to-uninstrumented-super behaviour is preserved for genuine instrumentation failures.

Tests

Adds regression coverage for both early-return paths — Sentry uninitialized, and a non-solid_queue adapter — asserting a raising job is performed exactly once and propagates its own error.

Both new examples fail on the old code with expected: 1, got: 2, and pass with the fix. Full gem suite: 62 examples, 0 failures. RuboCop clean.

Note that the raise_error assertions alone pass either way — only the execution counter catches the duplication. That is precisely why this went unnoticed.

🤖 Generated with Claude Code