When using Resque.inline, for acceptance tests, jobs with status will run inline, as if Resque.enqueue was synchronous.
When the job finishes Resque::Plugins::Status.enqueue will create a new hash overriding the one that was used within the job (when calling #at, for example).
This will make the job status be reset to 'queued', though it has just completed.
By moving Resque::Plugins::Status::Hash.create before the Resque.enqueue, we make the status available to the job as usual, and we don't override the status set by the job. If Resque.enqueue fails we remove the created hash, thus ensuring that we won't leave an unused hash.
quirkey
commented
12 years ago
When using Resque.inline, for acceptance tests, jobs with status will run inline, as if Resque.enqueue was synchronous.
When the job finishes Resque::Plugins::Status.enqueue will create a new hash overriding the one that was used within the job (when calling #at, for example).
This will make the job status be reset to 'queued', though it has just completed.
By moving Resque::Plugins::Status::Hash.create before the Resque.enqueue, we make the status available to the job as usual, and we don't override the status set by the job. If Resque.enqueue fails we remove the created hash, thus ensuring that we won't leave an unused hash.
When Resque.inline is not used it works as usual.