AFAIK, this was something that changed from 1.23.0 to 1.24.1. I'd imagine that the intended behavior here, given resque's forking architecture, would be for the parent process to continue running, place the job into the failure queue, and move on to the next. Also, we're not using the new "dont' fork" settings added in recent versions.
Here's the backtrace:
→ VVERBOSE=1 QUEUE=* bundle exec ./bin/rake environment resque:work
** [02:52:25 2013-04-17] 30473: Starting worker 12-345-67-890:1234:*
** [02:52:25 2013-04-17] 30473: Registered signals
** [02:52:25 2013-04-17] 30473: Pruning dead worker: 12-345-67-890:2345:*
** [02:52:25 2013-04-17] 30473: Failed to start worker : #<NameError: uninitialized constant JobClassThatNoLongerExists>
[GEM_ROOT]/gems/resque-1.24.1/lib/resque/helpers.rb:88:in `block in constantize`
[GEM_ROOT]/gems/resque-1.24.1/lib/resque/helpers.rb:82:in `each`
[GEM_ROOT]/gems/resque-1.24.1/lib/resque/helpers.rb:82:in `constantize`
[GEM_ROOT]/gems/resque-1.24.1/lib/resque/job.rb:166:in `payload_class`
[GEM_ROOT]/gems/newrelic_rpm-3.6.0.78/lib/new_relic/agent/instrumentation/resque.rb:49:in `payload_class`
[GEM_ROOT]/gems/resque-1.24.1/lib/resque/job.rb:217:in `failure_hooks`
[GEM_ROOT]/gems/resque-1.24.1/lib/resque/job.rb:223:in `run_failure_hooks`
[GEM_ROOT]/gems/resque-1.24.1/lib/resque/job.rb:177:in `fail`
[GEM_ROOT]/gems/resque-1.24.1/lib/resque/worker.rb:464:in `unregister_worker`
[GEM_ROOT]/gems/resque-1.24.1/lib/resque/worker.rb:176:in `rescue in work`
[GEM_ROOT]/gems/resque-1.24.1/lib/resque/worker.rb:130:in `work`
[GEM_ROOT]/gems/resque-1.24.1/lib/resque/tasks.rb:41:in `block (2 levels) in <top (required)>`
[GEM_ROOT]/gems/rake-10.0.3/lib/rake/task.rb:228:in `call`
[GEM_ROOT]/gems/rake-10.0.3/lib/rake/task.rb:228:in `block in execute`
[GEM_ROOT]/gems/rake-10.0.3/lib/rake/task.rb:223:in `each`
[GEM_ROOT]/gems/rake-10.0.3/lib/rake/task.rb:223:in `execute`
[GEM_ROOT]/gems/rake-10.0.3/lib/rake/task.rb:166:in `block in invoke_with_call_chain`
/home/deploy/.rbenv/versions/1.9.3-p392/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize`
[GEM_ROOT]/gems/rake-10.0.3/lib/rake/task.rb:159:in `invoke_with_call_chain`
[GEM_ROOT]/gems/rake-10.0.3/lib/rake/task.rb:152:in `invoke`
[GEM_ROOT]/gems/rake-10.0.3/lib/rake/application.rb:143:in `invoke_task`
[GEM_ROOT]/gems/rake-10.0.3/lib/rake/application.rb:101:in `block (2 levels) in top_level`
[GEM_ROOT]/gems/rake-10.0.3/lib/rake/application.rb:101:in `each`
[GEM_ROOT]/gems/rake-10.0.3/lib/rake/application.rb:101:in `block in top_level`
[GEM_ROOT]/gems/rake-10.0.3/lib/rake/application.rb:110:in `run_with_threads`
[GEM_ROOT]/gems/rake-10.0.3/lib/rake/application.rb:95:in `top_level`
[GEM_ROOT]/gems/rake-10.0.3/lib/rake/application.rb:73:in `block in run`
[GEM_ROOT]/gems/rake-10.0.3/lib/rake/application.rb:160:in `standard_exception_handling`
[GEM_ROOT]/gems/rake-10.0.3/lib/rake/application.rb:70:in `run`
[GEM_ROOT]/gems/rake-10.0.3/bin/rake:33:in `<top (required)>`
/var/www/payments/current/bin/rake:16:in `load`
/var/www/payments/current/bin/rake:16:in `<main>`
Yes, this should not kill the worker, for sure.
Just updating this ticket -- it's worth mentioning that this was a job coming from resque-scheduler. I'm not sure if the code path is different there, but I'm trying to write a spec that proves it one way or another.
Awesome, thanks.
I have the same issue, how can I avoid that?
Also posted the question here:
http://stackoverflow.com/questions/16802948/ignoring-unregister-worker-in-resque
Seeing this as well. There's no backtrace, so it's difficult to track down why there's a #<NameError: uninitialized constant MyConstant>
error in the job. This is all I see:
** Invoke environment (first_time)
** Execute environment
** Invoke resque:work (first_time)
** Invoke resque:preload (first_time)
** Invoke resque:setup (first_time)
** Execute resque:setup
** Execute resque:preload
** Invoke resque:setup
** Execute resque:work
*** Starting worker job21:8278:job_name
*** Registered signals
*** Pruning dead worker: job21:6807:job_queue
*** Failed to start worker : #<NameError: uninitialized constant MyConstant>
Any solution for this?
I have a solution to the NameError
killing the parent, but I want to try to find a way to reproduce this problem first so I can ensure that it actually solves it. Is it accurate to say that the problem can be reproduced by enqueueing a job with a class that doesn't exists?
Me having the same problem. Any solution for the NameError?
Like I said, I believe I have a solution, but I would like to be able to reliably recreate the problem first.
I am facing the same issue that the class is not found, i am using Contentful Scheduler https://github.com/contentful/contentful-scheduler.rb to publish and unpublish content and only while unpublishing contents i get this error randomly
uninitialized constant Contentful::Scheduler::Tasks::Unpublish Did you mean? Contentful::Scheduler::Tasks::Publish
/root/.gem/ruby/gems/resque-1.27.4/lib/resque.rb:96:in block in constantize'
/root/.gem/ruby/gems/resque-1.27.4/lib/resque.rb:90:in
each'
/root/.gem/ruby/gems/resque-1.27.4/lib/resque.rb:90:in `constantize'
Most helpful comment
Any solution for this?