Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rake resque:work aborts startup if the first job raises an uninitialized constant error #955

Open
ajsharp opened this issue Apr 17, 2013 · 11 comments

Comments

@ajsharp
Copy link

ajsharp commented Apr 17, 2013

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.

@ajsharp
Copy link
Author

ajsharp commented Apr 17, 2013

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>`

@steveklabnik
Copy link
Member

Yes, this should not kill the worker, for sure.

@ajsharp
Copy link
Author

ajsharp commented Apr 18, 2013

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.

@steveklabnik
Copy link
Member

Awesome, thanks.

@whoisstan
Copy link

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

@joevandyk
Copy link

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>

@abhi-patel
Copy link
Contributor

Any solution for this?

@corincerami
Copy link
Member

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?

@theaxel
Copy link

theaxel commented May 24, 2017

Me having the same problem. Any solution for the NameError?

@corincerami
Copy link
Member

Like I said, I believe I have a solution, but I would like to be able to reliably recreate the problem first.

@john007abhilash
Copy link

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'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants