There appears to be a bug when using resque-status with resque-scheduler that can cause jobs to be enqueued to the wrong queue.
This happens in the case where a developer defines the queue name not in the Job class itself (with a class variable or class method), but in a hash or yaml definition that is used to configure resque-scheduler. It appears that the resque-scheduler's README, where it talks about using resque-scheduler with resque-status, has an example like this, a case where the queue name would not be respected. From the resque-scheduler README:
SNIP
Let's pretend we have a JobWithStatus class called FakeLeaderboard
class FakeLeaderboard < Resque::JobWithStatus
def perform
# do something and keep track of the status
end
end
And then a schedule:
create_fake_leaderboards:
cron: "30 6 * * 1"
queue: scoring
custom_job_class: FakeLeaderboard
args:
rails_env: demo
description: "This job will auto-create leaderboards for our online demo and the status will update as the worker makes progress"
If your extension doesn't support scheduled job, you would need to extend the
custom job class to support the #scheduled method:
module Resque
class JobWithStatus
# Wrapper API to forward a Resque::Job creation API call into
# a JobWithStatus call.
def self.scheduled(queue, klass, *args)
create(*args)
end
end
end
END SNIP
In the above example, the actual queue that the job would be enqueud to is "statused", the default queue that Resque::JobWithStatus defines, and not "scoring" as the user would expect. You can see this is the case because the implementation of Job::scheduled above, taken from resque-status, does nothing with the queue name it is given. The disregard for the queue name makes me think for a second that it's intentional, but I can't think of why that would be.
This patch passes along the queue name that resque-scheduler passes in, so that the job is enqueued to the expected queue.
There appears to be a bug when using resque-status with resque-scheduler that can cause jobs to be enqueued to the wrong queue.
This happens in the case where a developer defines the queue name not in the Job class itself (with a class variable or class method), but in a hash or yaml definition that is used to configure resque-scheduler. It appears that the resque-scheduler's README, where it talks about using resque-scheduler with resque-status, has an example like this, a case where the queue name would not be respected. From the resque-scheduler README:
SNIP
Let's pretend we have a JobWithStatus class called FakeLeaderboard
And then a schedule:
If your extension doesn't support scheduled job, you would need to extend the custom job class to support the #scheduled method:
END SNIP
In the above example, the actual queue that the job would be enqueud to is "statused", the default queue that Resque::JobWithStatus defines, and not "scoring" as the user would expect. You can see this is the case because the implementation of Job::scheduled above, taken from resque-status, does nothing with the queue name it is given. The disregard for the queue name makes me think for a second that it's intentional, but I can't think of why that would be.
This patch passes along the queue name that resque-scheduler passes in, so that the job is enqueued to the expected queue.