Closed notmaxx closed 6 years ago
That's how code may look like
def perform_in(interval, *args)
return unless SuckerPunch::RUNNING.true?
queue = SuckerPunch::Queue.find_or_create(self.to_s, num_workers)
Concurrent::ScheduledTask.execute(interval.to_f, args: args, executor: queue) do
__run_perform(*args)
end
end
And this is how we'd use it
begin
...
watchdog = Jobs::....perform_in(2.minutes)
...
ensure
watchdog.cancel if watchdog
end
Sounds like a reasonable request. I'm a little hesitant exposing the underpinnings of concurrent-ruby and instance methods on it. I don't foresee a time when we'd switch, but it's still a risk that's not super clean. To run perform_in
and get back an object of some other class feels weird. I think, ideally, we'd delete with some return job class instance that has a #cancel
method that then called the underlying cancel
method on the ScheduledTask
.
Also, this is a breaking change, so versioning would have to be considered.
hi @brandonhilkert
How to cancel job that I scheduled with
perform_in
? This method returnsjob.pending?
status instead ofjob
itself (https://github.com/brandonhilkert/sucker_punch/blob/master/lib/sucker_punch/job.rb#L45). What do you think about returningjob
itself instead so it would be more functional? I can send PR with necessary change