sidekiq-scheduler / sidekiq-scheduler

Lightweight job scheduler extension for Sidekiq

Home Page:https://sidekiq-scheduler.github.io/sidekiq-scheduler/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support for Ruby 3.0 and deconstruct Hashes as keyword arguments.

abMatGit opened this issue · comments

We use sidekiq-schedule for a lot of periodically timed jobs. We have our configuration set up with keyword arguments since most of our jobs use keyword method signatures.

This results in our schedule to look like:
init/schedule.rb

schedule = {
  'morning job' => {
    class: 'MorningJob',
    cron: '0 8 * * * America/Los_Angeles',
    args: { foo: 'bar', hello: 'world' }
    persist: true
  }

... 
Sidekiq.configure_server do |config|
  config.on(:startup) do 
    schedule.each do |(name, schedule_config)|
      Sidekiq.set_schedule(name, schedule_config)
    end
  end
end

The issue is that args: { foo: 'bar', hello: 'world' } is passed along as a Hash, when we intend for it to be deconstructed as keyword arguments. This is a hard requirement for Ruby 3.0 which no longer allows Hashes to be auto-interpolated as keyword arguments.

Suggestion is to modify this method: https://github.com/sidekiq-scheduler/sidekiq-scheduler/blob/master/lib/sidekiq-scheduler/utils.rb#L63-L69 to have a condition for Hash and double splat in that scenario.

Won't this break if someone wants intentionally pass a hash as an argument? Just the first thing that comes to my mind, would have to test to see if it does or not

Yea that's a fair point. Arguably the same goes if someone wants to intentionally pass an Array as an argument too.

Perhaps we could make this more explicit in the config with a keyword_argument: true option.

yeah, I think I would prefer having this as an option in the config, or even at the job level, just so we avoid breaking someone's app that is relying on this behavior

@marcelolx okay added a commit for adding the keyword_argument: true but it makes things less clean. Definitely open to suggestions.

Added a spec as well.
Commit for your suggestion: 5c59f04

@abMatGit I think we can go with it as it is for now, even though it is less clean...