Fix superfluous SELECT when scheduling a single future job

[Mohammadalkhassawneh]

Problem

When a single job is enqueued, Execution subclasses (ScheduledExecution, ReadyExecution, BlockedExecution) each fire an extra SELECT solid_queue_jobs WHERE id = ? immediately before their INSERT.

The root cause is assume_attributes_from_job — a before_create callback that copies queue_name, priority, and any subclass-specific attributes from the job record:

def assume_attributes_from_job
  self.class.assumable_attributes_from_job.each do |attribute|
    send("\#{attribute}=", job.send(attribute))
  end
end

Because create_or_find_by!(job_id: id) only sets the job_id FK, the job association is not loaded. Calling job.send(attribute) lazy-loads it, triggering a SELECT. The bulk path (enqueue_all) already avoids this because insert_all bypasses ActiveRecord callbacks entirely. The single-job paths do not.

Fix

Pass job: self via the create_or_find_by! block so the association is already loaded in memory when assume_attributes_from_job fires:

# before
ScheduledExecution.create_or_find_by!(job_id: id)

# after
ScheduledExecution.create_or_find_by!(job_id: id) { |e| e.job = self }

Applied to all three single-job dispatch paths: schedule, ready, and block.