I'm not sure if this is intended behavior, but I was surprised by it.
In Getting Started, there's a code comment that suggests that use of Faktory::Job.set "dynamically override[s]" options. But, while it does, it also drops any other options that are defined on the Job. So, to use set you have to pass all the options to it, in order to override, say, just 1.
Here's some code that demonstrates the behavior, using the example job in the docs:
class SomeJob
include Faktory::Job
faktory_options queue: "critical", custom: { unique_for: 10.minutes.to_i }
def perform(*)
end
end
it 'fails to use the critical queue' do
SomeJob.set(custom: { unique_for: nil }).perform_async(1)
assert_equal 1, Faktory::Queues['default'].size
assert_equal 0, Faktory::Queues['critical'].size
end
I'm not sure if this is intended behavior, but I was surprised by it.
In Getting Started, there's a code comment that suggests that use of
Faktory::Job.set"dynamically override[s]" options. But, while it does, it also drops any other options that are defined on the Job. So, to usesetyou have to pass all the options to it, in order to override, say, just 1.Here's some code that demonstrates the behavior, using the example job in the docs: