Wrap Scheduler task execution with Rails reloader instead of executor to avoid database connection changing during code reload

[bensheldon]

Connects to #388.

Related to #95, and hopefully this PR does not produce deadlocks.

[jjb]

@bensheldon

I was recently reading https://guides.rubyonrails.org/threading_and_code_execution.html#reloader

and came across "Rails automatically wraps web requests and Active Job workers"

what do you know about how the need for this interacts with that alleged behavior?

I wonder if that statement only applies to the shipped async adapter and whoever wrote the docs wasn't precise?

[bensheldon]

@jjb great question! I think the documentation is written correctly, but GoodJob is a special case because GoodJob uses ActiveRecord to fetch-and-lock the serialized job data before it invokes ActiveJob. GoodJob has to wrap its code with the Rails Executor in order for GoodJob to work correctly, and then when ActiveJob is invoked, ActiveJob's usage of Rails Executor is a no-op. E.g. in psuedo code:

Thread.new do
  Rails.application.executor.wrap do
    GoodJob::Execution.fetch_and_lock_job do |job_params|
      ActiveJob.execute(job_params) do |job|
        Rails.application.executor.wrap do # noop
          job.perform
        end
      end
    end
  end
end

I think the Rails docs are assuming that the Thread is being invoked directly with the serialized job params primitives e.g.

Thread.new(job_params) do |thr_job_params|
  ActiveJob.execute(thr_job_params) do |job|
    Rails.application.executor.wrap do # noop
      job.perform
    end
  end
end

[jjb]

ahh gotcha, interesting - thanks for the explanation!