My company uses Resque in our Ruby on Rails app to handle asynchronous tasks that we don’t want to slow down interactive user requests.
Recently, we noticed that our Resque jobs were behaving weirdly; some were executing successfully, while others were reporting “uninitialized constant JobTypeJob” for the jobs we were enqueuing. We were at a lost to determine why this had suddenly started happening. Of course, we Googled “resque uninitialized constant” and tried all of the suggested causes and solutions we found, but none of them helped.
We finally figured out the problem, and it was sufficiently bizarre that I’m posting it here for Google to index on the off chance that somebody else runs into the same problem in the future and this saves them from having to spend many hours debugging it like we did.
Resque, of course, is backed by Redis. We use our Redis database for other things besides Resque, and we recently connected a our internal dashboard application to the our Redis database so that we could create internal dashboard pages to administer content in Redis. (Do you see where this is going yet?)
Now, the dashboard app also has its own Redis database, separate from the Redis database for our main application. The Redis database for the dashboard app is used for, among other things… the dashboard app’s own Resque. (Now do you see where this is going?)
Yes, indeed, when we configured the dashboard app to have access to our main app’s Redis database, we accidentally overwrote the Redis configuration for the dashboard app, and as a result, the dashboard app’s Resque worker was pulling jobs out of the main app’s Resque queue and trying to execute them.
Of course, they were failing, because the dashboard app doesn’t know about the main app’s job classes, hence the “uninitialized constant” errors.
TL;DR if you suddenly start getting “uninitialized constant” errors and your jobs aren’t running, then check and make sure you haven’t accidentally connected the wrong app to your Resque queue.
