bensheldon / good_job

In my development environment using the default async mode where requests run in a puma thread, if I have puma configured to use workers, and I make a change to a controller triggering ActionDispatch::Reloader to do it's thing that requests will block until the good job thread completes.

If I remove ActionDispatch::Reloader from the middleware stack the problem goes away, but obviously I'd like to keep that around for local development.

My short term fix is to disable workers and just use threads in development.

This is unfortunately expected behavior when running GoodJob in async execution moade. This is because GoodJob itself wraps job execution with a Reloader:

good_job/lib/good_job/scheduler.rb

Lines 275 to 279 in c308b79

    
           Rails.application.reloader.wrap do 
        
             thr_performer.next do |found| 
        
               thr_scheduler.create_thread({ fanout: fanout }) if found && fanout 
        
             end 
        
           end

This Reloader is necessary to prevent constants from being reloaded during job execution, which is unsafe. An job executed async is analogous to a similarly-long-running web request in a Puma thread, which would also block code reloading.

The options are:

Don't create long-running jobs in development
Run in external execution mode (inline will unfortunately also have this problem)

ok, that makes sense, thanks

	Rails.application.reloader.wrap do
	thr_performer.next do \|found\|
	thr_scheduler.create_thread({ fanout: fanout }) if found && fanout
	end
	end

Async mode blocks ActionDispatch::Reloader